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Abstract 


Applications involving smart cards have rapidly 
emerged since a few years. Up to now, chips are realized 
in conventional bulk technology. But as the need for 
performance rises, alternative technologies must be 
investigated. In this paper we study the feasibility of 
realizing the blocks for a smart card chip in Silicon-On- 
Insulator (SOI) technology. For most of the circuit 
blocks, SOI realization already exists and may be 
adapted for this application. However, we identified two 
circuits never fabricated in SOI: a charge pump and the 
random number generator. The charge pump has been 
realized in SOI and tested. A random signal source has 
also been realized. The circuit to create random bits, 


based on this source, is exposed. 


1. Introduction 


Applications involving smart cards have experienced a 
huge rise in recent years [1], [2], [3]. From simple 
memory cards at the origin, they evolved towards 
complex system-on-chip cards integrating memories, 
CPU, arithmetic co-processor and control logic. This 
opened new opportunities: smart cards can of course 
retain a huge amount of information compared to the 
magnetic strip cards, but they can also manage this 
information much more securely, using authentication 
The 


improvement is the possibility to process the information 


and user identification procedures. main 


directly on the card. 


Chips for smart cards follow the general trends in 


microelectronics [1]: towards small dimensions and 
The 


performances required from the electronic circuits are 


towards low-power, low-voltage circuits. 
more and more demanding [4]. Silicon-On-Insulator 
(SOD is a very good candidate to fabricate high 
performance, low-power low-voltage VLSI circuits. 

In the first part, we describe for which circuit blocks on 
the chip-card a realization already exists in SOI. 
Secondly, two circuits, which have never been processed 
in SOI, are realized and tested: the charge pump and a 
random signal source that can be used in a random 
number generator. 

The voltage multiplier or charge pump is used to 
generate a high voltage on-chip, in order to program 
non-volatile memories like EEPROM or Flash 
EEPROM. 

The random number generator generates a true random 
number that can be used during the authentication 
procedure. The intrinsic noise of transistors is used to 
generate a random signal. This random signal is sampled 
and transformed into a binary sequence. Statistical tests 
have been implemented to check whether the sequence 


has the characteristics of a true random sequence. 


2. Silicon-On-Insulator technology 


Silicon-On-Insulator transistors are fabricated in a small 
(~100 nm) layer of silicon, located on top of a silicon 
dioxide layer, called buried oxide. This oxide layer 


provides full dielectric isolation of the transistor, and 
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thus, most of the parasitic effects present in bulk silicon 
transistors are eliminated. 

The structure of the SOI transistor is depicted in figure 1 
(a), and is very similar to the structure of the bulk 
transistor (figure 1 (b)). The main difference is the 


presence of the buried oxide. 


Ve 
Vs eeeeleeemens VO 
| ch j 
N N 
"Buried oxide - 


| Silicon substrate | 


(a) SOI Transistor 


Silicon substrate 





(b) Bulk-Si Transistor 


Figure 1: Structure ofa SOI MOS transistor (a) and 
a bulk-Si MOS transistor (b). 


The presence of this buried oxide provides attractive 

properties to the SOI transistor. 

The main advantages of SOI technology are summarized 

below [5], [6] : 

e latchup of the parasitic PNPN thyristor in CMOS 
circuits is eliminated, 

e reduction of source and drain junction capacitances, 
which makes high speed operation possible, 

e lower sensitivity to transient radiation effects, 

e the fabrication technology is fully compatible with a 
conventional bulk CMOS process; the SOI process 
involves even less steps, 

e higher integration density, 


e high temperature operation. 
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If, in addition, the silicon film is made so thin that full 

depletion operation is achieved [6], the following 

advantages are also gained: 

e improved subthreshold slope, and thus the possibility 
to lower the threshold voltage of the transistor 
without increasing the off-current, 


e reduced body effect. 


The most attractive properties for smart card 
applications are: lower operating voltage without loss of 
speed and the enhanced security. The latter is improved 
in three ways. Firstly, SOI technology allows the use of 
more compact layouts, which makes probing more 
difficult. Secondly, due to the lower power and current 
consumption, it will be less easy to measure the 
variations of these quantities. Finally, SOI circuits are 
recognized to operate well in harsh environments 
high radiation 


especially in temperature and 


environments. 


3. Chip-card circuits 


Based on the structure of the chip on a smart card (figure 
2) [1], [7], [8], [9], we investigated the blocks already 
available in SOI technology and the compatibility of 


their performance with the smart card application. 


CHARGE 
PUMP 


OSCILLATOR 





CONTROL 


ck — PLL LOGIC 


Rst — TIME BASE 
Vdd — WATCHDOG 
Vss — 


Figure 2: Architecture of the chip for smart card 


cs 
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CONTROL 





applications {1}, [8]. 


3.1 CPU 

Many promising results have been published about 
processors in SOI. A research team from Motorola has 
made the first very low-power low-voltage CPU-core in 
SOI [10]. It showed superior performances compared to 


similar bulk realizations. For example, at 0.9 V supply 
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voltage, the SOI processor is twice as fast as a similar 
bulk processor. 

A test version of the Strong ARM-110 has been 
processed and tested by Digital Equipment [11]. It 
showed a performance improvement of at least 20 % 
over the equivalent bulk circuit, and a gain of 30 % in 
power dissipation. 

Other SOI logic circuits include Gate Arrays [12], [13] 
and ALU’s [14]. In each case, the SOI circuits can 
operate faster than comparable bulk circuits, and can still 
operate at lower voltages. 

These gains in performance, and especially the low- 
voltage operation, are significant regarding the smart 


card application. 


3.2 Clock generation circuits 

In a smart card, a clock signal is provided by the outside 
world and is supplied to an on-chip clock regeneration 
circuit, in order to stabilize the signal and to prevent 
clock signal manipulations. The circuit can be 
implemented as a Phase-Locked Loop (PLL). Such 
circuits have been made in SOI. For example, NTT has 
developed a PLL that operates at 2 V supply voltage, up 
to a frequency of 2 GHz [15], [16]. This shows that it is 
possible to conceive low-voltage clock regeneration 


circuits in SOI for the smart card application. 


3.3 Memories 

Three types of memory are present on the smart card 
chip: ROM, RAM and non-volatile memory like 
EEPROM or Flash EEPROM [7]. 

The ROM is programmed by mask during device 
fabrication and no particular problem is encountered. 
One example of SOI realization can be found in the 
CPU core described above [10]. 

The RAM of smart cards is currently Static RAM 
(SRAM). The main reason is the possibility to use a 
power-saving mode [9]: when the CPU stays in sleep 
mode, the clock is fixed to the high or the low level 
permanently. Whereas a Dynamic RAM (DRAM) needs 
to be periodically refreshed, the SRAM doesn’t need this 


and the presence of the supply voltage is sufficient to 


retain the information. 

A SRAM cell occupies more die area than a DRAM cell 
(6 transistors vs. one transistor and a tiny capacitor), but 
this is compensated by the absence of refresh circuit for 
small memories (36...256 bytes). Several manufacturers 
master well the fabrication of SOI-SRAM [17], [18] 
and SOI-DRAM [19], [20] for some years now, with 
speed and power performances superior to conventional 
bulk silicon memories. 

Most of the chip cards carry their user-specific 
information in an EEPROM or Flash EEPROM 
memory. Although the research in the field of the non- 
volatile memories in SOI is more recent, some 
realizations can be found. Martignone [21] described an 
EEPROM-based cell realized in the SOI CMOS 
technology of the UCL Microelectronics Laboratory. 
Gog! et al. realized a single-polysilicon EEPROM-cell in 
SOI technology for high temperature applications [22]. 
Two Flash EEPROM cells were described, one [23] 
fabricated in the UCL Microelectronics Laboratory, the 
other [24] fabricated by National Semiconductor. 


4. New circuits in SOI 

From the previous investigation, we identified two 
circuits which have never been realized in SOI : the 
charge pump and the random number generator. In the 
present work, a charge pump has been realized in the 
SOL-CMOS 2 yum UCL 


Microelectronics Laboratory. The architecture of a 


technology of the 


random number generator is also proposed. It is based 
on a random signal generator, realized in SOI, and some 
additional components to transform the random signal in 
a stream of random bits. These components are external 
discrete components in the present implementation, but 


could easily be integrated in SOI technology. 


4.1 The charge pump 

Charge pump circuits, or voltage multipliers, are 
required to program the non-volatile memory. EEPROM 
or Flash EEPROM cells need a high voltage to be 
programmed, formerly 20 V, now towards 5 V. It can be 


generated on-chip from the lower supply voltage with a 
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charge pump circuit. Most of these circuits are based on 
the Dickson charge pump [25], [26] (figure 3). 


Veo Vi Vat | Va | View Vu. Vn Vout 


tr Pe 
ee 


Figure 3: Dickson voltage multiplier [25]. 


The electric charges are pumped from node to node, 
from the supply to the output node. The pumping is 
achieved by charging and discharging the capacitors, 


under influence of the complementary clock signals ® 


and O, The voltage increases from node to node, to 
reach the final voltage on the output node. 

In CMOS technology, the diodes are replaced by MOS 
transistors, which have their gate and drain in short- 


circuit. The circuit we have realized is shown in figure 4. 
Vec 


CLK 





Voc Vout 


Figure 4: Schematic of the charge pump circuit 


realized in the Microelectronics Laboratory. 


The external clock signal (CLK) is fed to the MOS 
diodes through two inverters, to get complementary 
signals. An amplifier in follower configuration has been 
placed at the output terminal in our test implementation 
in order to reduce the coupling between the load 
capacitance and the output voltage during the 
measurements. This would not be present in a practical 
EEPROM architecture. 

The experimental results are presented in figure 5 and 
compared to the theoretical prediction of an analytical 


modeling. 
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For low supply voltages, the experimental points follow 
the theoretical curve fairly well. For supply voltages 
above 1.4 V, a saturation phenomenon can be observed. 
This is due to the limitation of the dynamic range of the 
follower-amplifier placed at the output. 

It can be observed that the supply voltage is multiplied 


by a factor of three, which was the target of our 
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Figure 5: Experimental (*) and theoretical (-) results 
for the charge pump circuit. This figure presents the 
output voltage Vw vs. supply voltage V... 


application. A programming voltage of 5 V could be 
obtained from a supply voltage of 1.8 V in a practical 
EEPROM implementation (without measurement output 


amplifier). 


4.2 The random number generator 

4.2.1 Design of the generator 

The random number generator in the smart card is used 
during the authentication procedure [9]. The terminal 
asks a random number to the card. The smart card 
encrypts it, and sends it to the terminal. If the terminal is 
able to decipher the number, it is authenticated by the 
card. Most of the generators used in current smart cards 
are based on deterministic algorithms expanding a 
random seed, thus producing «pseudo-random 
numbers». But the security of the application is not 
necessarily guaranteed [27]. 

In this work we propose to develop a hardware random 
number generator, producing true random numbers. In 


the literature, very few realizations of integrated random 
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number generators are described [28]. Some examples 
of random signal sources are: the frequency instability of 
an oscillator [28], the noise of semiconductors [29], 
[30], the time between two radioactive emissions [31], 
the number of charges in a MOS capacitor structure 
[32]. 

We use the intrinsic noise of transistors as random 
signal. It presents the advantage of being present in the 
integrated circuit itself. It is easy to use in low voltage 
applications. 

A single-stage Operational Transconductance Amplifier 
(OTA) is used to produce noise (figure 6). 


41 M6 


Out 


M8 





Vss 


Figure 6: Single-stage OTA used to produce noise. 


This OTA is designed to produce a high level of noise at 
its output. The most important contribution comes from 
the input differential pair M1 and M2 [33]. 

The noise source is integrated in a more global 
architecture, presented in figure 7. 

The experimental circuit is composed of two parts: the 
random signal generator, integrated in SOI, represented 


in the box in figure 7, and some external circuitry made 








IC - SOl 


Noise 
Source 2 






Comparator 


up of discrete components. 

The random signal generator uses two independent noise 
sources. Their outputs provide a random signal of a few 
microvolts of amplitude, set around a fixed DC level. 
The two signals are fed into a comparator. Provided that 
the DC levels are the same on each comparator input, the 
comparator will switch randomly from one level to the 
other. The produced signal will be an analog random 
signal. The bandpass filter (B.P. filter in figure 7) selects 
the frequency band, and thus eliminates parasitic signals 
at low and high frequencies. 

The random analog signal is then sampled and compared 
to a reference value. This reference value must be the 
mean of the random signal. The clock signal used for the 
sampling determines the speed at which the random bits 
will be produced. 

4.2.2 Experimental results 

The output signal of the SOI random signal generator is 
shown in figure 8. The random signal is modulated by a 
low frequency signal. The band-pass filter will eliminate 
the latter. 

Sequences of random bits were produced using this 
random signal in the circuit described above. Menezes et 
al. ( [34], Chapter 5, pp. 169-190 ) propose S statistical 
tests to check for the randomness of the sequences: the 
equidistribution test, the serial test, the gap test, the 
poker test, the runs test and the autocorrelation test. 
When applying the tests to the produced sequences, only 
11 % of them pass the 5 tests successfully. The other 
sequences present a bias, that is a clear preference for 
«0»’s or «1»’s. This seems to be a general phenomenon 


affecting hardware random number generators [34]. 


CLK 


00101... 


Figure 7 : Complete architecture of the random number generator. 
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Figure 8 : Output voltage of the SOI random signal generator vs. time. 


It is possible to de-skew the sequences by using de- 
skewig algorithms. Here we used Von Neumann’s 
method and the parity bit method [27]. In that case, 96 
% of the produced sequences pass the 5 statistical tests. 


5. Conclusion 

The objective of this work was to demonstrate the 
feasibility of realizing the smart card IC in Silicon-On- 
Insulator (SOI) technology. In the first part, we 
established the global architecture, and we checked in 
the literature which circuit blocks have already been 
demonstrated in SOI. For most of the circuit parts, a 
realization exists, and can be adapted for use in the smart 
card. 

We identified two circuit blocks, never realized in SOI 
up to now to our knowledge : the charge pump, and a 
random number generator. 

The charge pump has been realized and tested. 

A new architecture for a random number generator is 
proposed. A random signal generator has been 
processed in SOI and is used to produce random 
numbers. In the next version of the generator, a 
regulation circuit for the DC levels must be included. 
This will enhance the immunity to external effects 


(temperature, electromagnetic waves). 
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Abstract 


We describe techniques for extracting protected 
software and data from smartcard processors. This 
includes manual microprobing, laser cutting, fo- 
cused ion-beam manipulation, glitch attacks, and 
power analysis. Many of these methods have already 
been used to compromise widely-fielded conditional- 
access systems, and current smartcards offer little 
protection against them. We give examples of low- 
cost protection concepts that make such attacks con- 
siderably more difficult. 


1 Introduction 


Smartcard piracy has become a common occur- 
rence. Since around 1994, almost every type of 
smartcard processor used in European, and later also 
American and Asian, pay-TV conditional-access sys- 
tems has been successfully reverse engineered. Com- 
promised secrets have been sold in the form of il- 
licit clone cards that decrypt TV channels without 
revenue for the broadcaster. The industry has had 
to update the security processor technology several 
times already and the race is far from over. 

Smartcards promise numerous security benefits. 
They can participate in cryptographic protocols, and 
unlike magnetic stripe cards, the stored data can be 
protected against unauthorized access. However, the 
strength of this protection seems to be frequently 
overestimated. 

In Section 2, we give a brief overview on the 
most important hardware techniques for breaking 
into smartcards. We aim to help software engineers 
without a background in modern VLSI test tech- 
niques in getting a realistic impression of how phys- 
ical tampering works and what it costs. Based on 
our observations of what makes these attacks par- 
ticularly easy, in Section 3 we discuss various ideas 
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for countermeasures. Some of these we believe to be 
new, while others have already been implemented in 
products but are either not widely used or have de- 
sign flaws that have allowed us to circumvent them. 


2 Tampering Techniques 
We can distinguish four major attack categories: 


e Microprobing techniques can be used to access 
the chip surface directly, thus we can observe, ma- 
nipulate, and interfere with the integrated circuit. 


e Software attacks use the normal communica- 
tion interface of the processor and exploit secu- 
rity vulnerabilities found in the protocols, cryp- 
tographic algorithms, or their implementation. 


e Eavesdropping techniques monitor, with high 
time resolution, the analog characteristics of all 
supply and interface connections and any other 
electromagnetic radiation produced by the pro- 
cessor during normal operation. 


e Fault generation techniques use abnormal en- 
vironmental conditions to generate malfunctions 
in the processor that provide additional access. 


All microprobing techniques are invasive attacks. 
They require hours or weeks in a specialized labora- 
tory and in the process they destroy the packaging. 
The other three are non-invasive attacks. After we 
have prepared such an attack for a specific proces- 
sor type and software version, we can usually repro- 
duce it within seconds on another card of the same 
type. The attacked card is not physically harmed 
and the equipment used in the attack can usually be 
disguised as a normal smartcard reader. 

Non-invasive attacks are particularly dangerous 
in some applications for two reasons. Firstly, the 
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owner of the compromised card might not notice 
that the secret keys have been stolen, therefore it 
is unlikely that the validity of the compromised keys 
will be revoked before they are abused. Secondly, 
non-invasive attacks often scale well, as the neces- 
sary equipment (e.g., a small DSP board with special 
software) can usually be reproduced and updated at 
low cost. 

The design of most non-invasive attacks requires 
detailed knowledge of both the processor and soft- 
ware. On the other hand, invasive microprobing at- 
tacks require very little initial knowledge and usually 
work with a similar set of techniques on a wide range 
of products. Attacks therefore often start with in- 
vasive reverse engineering, the results of which then 
help to develop cheaper and faster non-invasive at- 
tacks. We have seen this pattern numerous times on 
the conditional-access piracy market. 

Non-invasive attacks are of particular concern in 
applications where the security processor is primar- 
ily required to provide tamper evidence, while inva- 
sive attacks violate the tamper-resistance character- 
istics of a card [1]. Tamper evidence is of primary 
concern in applications such as banking and digi- 
tal signatures, where the validity of keys can easily 
be revoked and where the owner of the card has al- 
ready all the access that the keys provide anyway. 
Tamper resistance is of importance in applications 
such as copyright enforcement, intellectual property 
protection, and some electronic cash schemes, where 
the security of an entire system collapses as soon as 
a few cards are compromised. 

To understand better which countermeasures are 
of practical value, we first of all have to understand 
the techniques that pirates have used so far to break 
practically all major smartcard processors on the 
market. In the next section, we give a short guided 
tour through a typical laboratory of a smartcard pi- 
rate. 


2.1 Invasive Attacks 


2.1.1 Depackaging of Smartcards 


Invasive attacks start with the removal of the chip 
package. We heat the card plastic until it becomes 
flexible. This softens the glue and the chip mod- 
ule can then be removed easily by bending the card. 
We cover the chip module with 20-50 ml of fuming 
nitric acid heated to around 60 °C and wait for the 
black epoxy resin that encapsulates the silicon die to 
completely dissolve (Fig. 1). The procedure should 
preferably be carried out under very dry conditions, 
as the presence of water could corrode exposed alu- 
minium interconnects. The chip is then washed with 
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Figure 1: Hot fuming nitric acid (> 98% HNO3) 
dissolves the package without affecting the chip. 





Figure 2: The depackaged smartcard processor is 
glued into a test package, whose pins are then con- 
nected to the contact pads of the chip with fine alu- 
minium wires in a manual bonding machine. 


acetone in an ultrasonic bath, followed optionally by 
a short bath in deionized water and isopropanol. We 
remove the remaining bonding wires with tweezers, 
glue the die into a test package, and bond its pads 
manually to the pins (Fig. 2). Detailed descriptions 
of these and other preparation techniques are given 
in (2, 3]. 


2.1.2 Layout Reconstruction 


The next step in an invasive attack on a new pro- 
cessor is to create a map of it. We use an optical 
microscope with a CCD camera to produce several 
meter large mosaics of high-resolution photographs 
of the chip surface. Basic architectural structures, 
such as data and address bus lines, can be identi- 
fied quite quickly by studying connectivity patterns 
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Figure 3: Left: CMOS AND gate imaged by a con- 
focal microscope. Right: same gate after removal of 
metal layer (HF wet etching). Polysilicon intercon- 
nects and diffusion areas are now fully visible. 


and by tracing metal lines that cross clearly visible 
module boundaries (ROM, RAM, EEPROM, ALU, 
instruction decoder, etc.). All processing modules 
are usually connected to the main bus via easily rec- 
ognizable latches and bus drivers. The attacker ob- 
viously has to be well familiar with CMOS VLSI 
design techniques and microcontroller architectures, 
but the necessary knowledge is easily available from 
numerous textbooks [4, 5, 6, 7]. 

Photographs of the chip surface show the top 
metal layer, which is not transparent and therefore 
obscures the view on many structures below. Un- 
less the oxide layers have been planarized, lower 
layers can still be recognized through the height 
variations that they cause in the covering layers. 
Deeper layers can only be recognized in a second se- 
ries of photographs after the metal layers have been 
stripped off, which we achieve by submerging the 
chip for a few seconds in hydrofluoric acid (HF) in an 
ultrasonic bath [2]. HF quickly dissolves the silicon 
oxide around the metal tracks and detaches them 
from the chip surface. HF is an extremely dangerous 
substance and safety precautions have to be followed 
carefully when handling it. 

Figure 3 demonstrates an optical layout recon- 
struction of a NAND gate followed by an inverter. 
These images were taken with a confocal micro- 
scope (Zeiss Axiotron-2 CSM), which assigns differ- 
ent colors to different focal planes (e.g., metal=blue, 
polysilicon=green) and thus preserves depth infor- 
mation [8]. Multilayer images like those shown in 
Fig. 3 can be read with some experience almost as 
easily as circuit diagrams. These photographs help 
us in understanding those parts of the circuitry that 
are relevant for the planned attack. 

If the processor has a commonly accessible stan- 
dard architecture, then we have to reconstruct the 
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Figure 4: The vias in this structure found in a 
ST16F48A form a permutation matrix between the 
memory readout column lines and the 16:1 demulti- 
plexer. The applied mapping remains clearly visible. 





layout only until we have identified those bus lines 
and functional modules that we have to manipulate 
to access all memory values. More recently, design- 
ers of conditional-access smartcards have started to 
add proprietary cryptographic hardware functions 
that forced the attackers to reconstruct more com- 
plex circuitry involving several thousand transistors 
before the system was fully compromised. How- 
ever, the use of standard-cell ASIC designs allows 
us to easily identify logic gates from their diffusion 
area layout, which makes the task significantly easier 
than the reconstruction of a transistor-level netlist. 

Some manufacturers use non-standard instruction 
sets and bus-scrambling techniques in their secu- 
rity processors. In this case, the entire path from 
the EEPROM memory cells to the instruction de- 
coder and ALU has to be examined carefully before 
a successful disassembly of extracted machine code 
becomes possible. However, the attempts of bus 
scrambling that we encountered so far in smartcard 
processors were mostly only simple permutations of 
lines that can be spotted easily (Fig. 4). 

Any good microscope can be used in optical VLSI 
layout reconstruction, but confocal microscopes have 
a number of properties that make them particularly 
suited for this task. While normal microscopes pro- 
duce a blurred image of any plane that is out of fo- 
cus, in confocal scanning optical microscopes, every- 
thing outside the focal plane just becomes dark [8]. 
Confocal microscopes also provide better resolution 
and contrast. A chromatic lens in the system can 
make the location of the focal plane wavelength de- 
pendent, such that under white light different layers 
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Figure 5: The data of this NOR ROM becomes 
clearly visible when the covering metal and polysili- 
con access lines plus the surrounding field oxide have 
been removed (HF wet etching). The image shows 
16 x 10 bits in an ST16xyz. Every bit is represented 
by either a present or missing diffusion layer connec- 
tion. 


of the chip will appear simultaneously, but in differ- 
ent colors. 

Automatic layout reconstruction has been demon- 
strated with scanning electron microscopy [9]. We 
consider confocal microscopy to be an attractive al- 
ternative, because we do not need a vacuum envi- 
ronment, the depth information is preserved, and 
the option of oil immersion allows the hiding of un- 
evenly removed oxide layers. With UV microscopy, 
even chip structures down to 0.1 um can be resolved. 

With semiautomatic image-processing methods, 
significant portions of a processor can be reverse 
engineered within a few days. The resulting poly- 
gon data can then be used to automatically generate 
transistor and gate-level netlists for circuit simula- 
tions. 

Optical reconstruction techniques can also be 
used to read ROM directly. The ROM bit pattern 
is stored in the diffusion layer, which leaves hardly 
any optical indication of the data on the chip sur- 
face. We have to remove all covering layers using HF 
wet etching, after which we can easily recognize the 
rims of the diffusion regions that reveal the stored 
bit pattern (Fig. 5). 

Some ROM technologies store bits not in the 
shape of the active area but by modifying transistor 
threshold voltages. In this case, additional dopant- 
selective staining techniques have to be applied to 
make the bits visible (Fig. 6). Together with an 
understanding of the (sometimes slightly scrambled, 
see Fig. 4) memory-cell addressing, we obtain disas- 
sembler listings of the entire ROM content. Again, 
automated processing techniques can be used to ex- 
tract the data from photos, but we also know cases 
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Figure 6: The implant-mask layout of a NAND 
ROM can be made visible by a dopant-selective 


crystallographic etch (Dash etchand [2]). This im- 
age shows 16 x 14 bits plus parts of the row selec- 
tor of a ROM found on an MC68HC05SC22 CPU. 
The threshold voltage of 0-bit p-channel transistors 
(stained dark here) was brought below 0 V through 
ion implantation. 


where an enthusiastic smartcard hacker has recon- 
structed several kilobytes of ROM manually. 

While the ROM usually does not contain any 
cryptographic key material, it does often contain 
enough I/O, access control, and cryptographic rou- 
tines to be of use in the design of a non-invasive 
attack. 


2.1.3 Manual Microprobing 


The most important tool for invasive attacks is a 
microprobing workstation. Its major component is 
a special optical microscope (e.g., Mitutoyo FS-60) 
with a working distance of at least 8 mm between 
the chip surface and the objective lens. On a stable 
platform around a socket for the test package, we in- 
stall several micropositioners (e.g., from Karl Suss, 
Micromanipulator, or Wentworth Labs), which allow 
us to move a probe arm with submicrometer preci- 
sion over a chip surface. On this arm, we install a 
“cat whisker” probe (e.g., Picoprobe T-4-10). This 
is a metal shaft that holds a 10 ym diameter and 
5 mm long tungsten-hair, which has been sharpened 
at the end into a < 0.1 wm tip. These elastic probe 
hairs allow us to establish electrical contact with on- 
chip bus lines without damaging them. We connect 
them via an amplifier to a digital signal processor 
card that records or overrides processor signals and 
also provides the power, clock, reset, and I/O signals 
needed to operate the processor via the pins of the 
test package. 

On the depackaged chip, the top-layer aluminium 
interconnect lines are still covered by a passivation 
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Figure 7: This image shows 9 horizontal bus lines 
on a depackaged smartcard processor. A UV laser 
(355 nm, 5 ns) was used to remove small patches of 
the passivation layer over the eight dat a-bus lines to 
provide for microprobing access. 


layer (usually silicon oxide or nitride), which pro- 
tects the chip from the environment and ion migra- 
tion. On top of this, we might also find a poly- 
imide layer that was not entirely removed by HNO3 
but which can be dissolved with ethylendiamine. 
We have to remove the passivation layer before the 
probes can establish contact. The most convenient 
depassivation technique is the use of a laser cutter 
(e.g., from New Wave Research). 

The UV or green laser is mounted on the camera 
port of the microscope and fires laser pulses through 
the microscope onto rectangular areas of the chip 
with micrometer precision. Carefully dosed laser 
flashes remove patches of the passivation layer. The 
resulting hole in the passivation layer can be made so 
small that only a single bus line is exposed (Fig. 7). 
This prevents accidental contacts with neighbouring 
lines and the hole also stabilizes the position of the 
probe and makes it less sensitive to vibrations and 
temperature changes. 

Complete microprobing workstations cost tens of 
thousands of dollars, with the more luxurious ver- 
sions reaching over a hundred thousand US$. The 
cost of a new laser cutter is roughly in the same 
region. 

Low-budget attackers are likely to get a cheaper 
solution on the second-hand market for semicon- 
ductor test equipment. With patience and skill it 
should not be too difficult to assemble all the re- 
quired tools for even under ten thousand US$ by 
buying a second-hand microscope and using self- 
designed micropositioners. The laser is not essential 
for first results, because vibrations in the probing 
needle can also be used to break holes into the pas- 
sivation. 
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2.1.4 Memory Read-out Techniques 


It is usually not practical to read the information 
stored on a security processor directly out of each 
single memory cell, except for ROM. The stored data 
has to be accessed via the memory bus where all data 
is available at a single location. Microprobing is used 
to observe the entire bus and record the values in 
memory as they are accessed. 

It is difficult to observe all (usually over 20) data 
and address bus lines at the same time. Various 
techniques can be used to get around this problem. 
For instance we can repeat the same transaction 
many times and use only two to four probes to ob- 
serve various subsets of the bus lines. As long as 
the processor performs the same sequence of mem- 
ory accesses each time, we can combine the recorded 
bus subset signals into a complete bus trace. Over- 
lapping bus lines in the various recordings help us 
to synchronize them before they are combined. 

In applications such as pay-TV, attackers can eas- 
ily replay some authentic protocol exchange with 
the card during a microprobing examination. These 
applications cannot implement strong replay pro- 
tections in their protocols, because the transaction 
counters required to do this would cause an NVRAM 
write access per transaction. Some conditional- 
access cards have to perform over a thousand pro- 
tocol exchanges per hour and EEPROM technology 
allows only 104-10° write cycles during the lifetime 
of a storage cell. An NVRAM transaction counter 
would damage the memory cells, and a RAM counter 
can be reset by the attacker easily by removing 
power. Newer memory technologies such as FERAM 
allow over 10° write cycles, which should solve this 
problem. 

Just replaying transactions might not suffice to 
make the processor access all critical memory loca- 
tions. For instance, some banking cards read criti- 
cal keys from memory only after authenticating that 
they are indeed talking to an ATM. Pay-TV card 
designers have started to implement many different 
encryption keys and variations of encryption algo- 
rithms in every card, and they switch between these 
every few weeks. The memory locations of algorithm 
and key variations are not accessed by the proces- 
sor before these variations have been activated by a 
signed message from the broadcaster, so that passive 
monitoring of bus lines will not reveal these secrets 
to an attacker early. 

Sometimes, hostile bus observers are lucky and 
encounter a card where the programmer believed 
that by calculating and verifying some memory 
checksum after every reset the tamper-resistance 
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could somehow be increased. ‘This gives the at- 
tacker of course easy immediate access to all memory 
locations on the bus and simplifies completing the 
read-out operation considerably. Surprisingly, such 
memory integrity checks were even suggested in the 
smartcard security literature (10], in order to defeat 
a proposed memory rewrite attack technique [11]. 
This demonstrates the importance of training the 
designers of security processors and applications in 
performing a wide range of attacks before they start 
to design countermeasures. Otherwise, measures 
against one attack can far too easily backfire and 
simplify other approaches in unexpected ways. 

In order to read out all memory cells without the 
help of the card software, we have to abuse a CPU 
component as an address counter to access all mem- 
ory cells for us. The program counter is already 
incremented automatically during every instruction 
cycle and used to read the next address, which makes 
it perfectly suited to serve us as an address sequence 
generator [12]. We only have to prevent the proces- 
sor from executing jump, call, or return instructions, 
which would disturb the program counter in its nor- 
mal read sequence. Tiny modifications of the in- 
struction decoder or program counter circuit, which 
can easily be performed by opening the right metal 
interconnect with a laser, often have the desired ef- 
fect. 


2.1.5 Particle Beam Techniques 


Most currently available smartcard processors have 
feature sizes of 0.5~1 um and only two metal lay- 
ers. These can be reverse-engineered and observed 
with the manual and optical techniques described 
in the previous sections. For future card genera- 
tions with more metal layers and features below the 
wavelength of visible light, more expensive tools ad- 
ditionally might have to be used. 

A focused ion beam (FIB) workstation consists of 
a vacuum chamber with a particle gun, comparable 
to a scanning electron microscope (SEM). Gallium 
ions are accelerated and focused from a liquid metal 
cathode with 30 kV into a beam of down to 5~10 nm 
diameter, with beam currents ranging from 1 pA to 
10 nA. FIBs can image samples from secondary par- 
ticles similar to a SEM with down to 5 nm resolution. 
By increasing the beam current, chip material can be 
removed with the same resolution at a rate of around 
0.25 pm? nA~'s-! [13]. Better etch rates can be 
achieved by injecting a gas like iodine via a needle 
that is brought to within a few hundred micrometers 
from the beam target. Gas molecules settle down on 
the chip surface and react with removed material to 


form a volatile compound that can be pumped away 
and is not redeposited. Using this gas-assisted etch 
technique, holes that are up to 12 times deeper than 
wide can be created at arbitrary angles to get ac- 
cess to deep metal layers without damaging nearby 
structures. By injecting a platinum-based organo- 
metallic gas that is broken down on the chip surface 
by the ion beam, platinum can be deposited to es- 
tablish new contacts. With other gas chemistries, 
even insulators can be deposited to establish surface 
contacts to deep metal without contacting any cov- 
ering layers. 

Using laser interferometer stages, a FIB operator 
can navigate blindly on a chip surface with 0.15 pm 
precision, even if the chip has been planarized and 
has no recognizable surface structures. Chips can 
also be polished from the back side down to a thick- 
ness of just a few tens of micrometers. Using laser- 
interferometer navigation or infrared laser imaging, 
it is then possible to locate individual transistors and 
contact them through the silicon substrate by FIB 
editing a suitable hole. This rear-access technique 
has probably not yet been used by pirates so far, 
but the technique is about to become much more 
commonly available and therefore has to be taken 
into account by designers of new security chips. 

FIBs are used by attackers today primarily to 
simplify manual probing of deep metal and polysil- 
icon lines. A hole is drilled to the signal line of in- 
terest, filled with platinum to bring the signal to 
the surface, where a several micrometer large prob- 
ing pad or cross is created to allow easy access 
(Fig. 11). Modern FIB workstations (for example 
the FIB 200xP from FEI) cost less than half a mil- 
lion US$ and are available in over hundred organiza- 
tions. Processing time can be rented from numerous 
companies all over the world for a few hundred dol- 
lars per hour. 

Another useful particle beam tool are electron- 
beam testers (EBT) [14]. These are SEMs with a 
voltage-contrast function. Typical] acceleration volt- 
ages and beam currents for the primary electrons 
are 2.5 kV and 5 nA. The number and energy of sec- 
ondary electrons are an indication of the local elec- 
tric field on the chip surface and signal lines can be 
observed with submicrometer resolution. The signal 
generated during e-beam testing is essentially the 
low-pass filtered product of the beam current mul- 
tiplied with a function of the signal voltage, plus 
noise. EBTs can measure waveforms with a band- 
width of several gigahertz, but only with periodic 
signals where stroboscopic techniques and periodic 
averaging can be used. If we use real-time voltage- 
contrast mode, where the beam is continuously di- 
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rected to a single spot and the blurred and noisy 
stream of secondary electrons is recorded, then the 
signal bandwidth is limited to a few megahertz [14]. 
While such a bandwidth might just be sufficient for 
observing a single signal line in a 3.5 MHz smart- 
card, it is too low to observe an entire bus with a 
sample frequency of several megahertz for each line. 

EBTs are very convenient attack tools if the clock 
frequency of the observed processor can be reduced 
below 100 kHz to allow real-time recording of all bus 
lines or if the processor can be forced to generate 
periodic signals by continuously repeating the same 
transaction during the measurement. 


2.2 Non-invasive Attacks 


A processor is essentially a set of a few hundred 
flipflops (registers, latches, and SRAM cells) that de- 
fine its current state, plus combinatorial logic that 
calculates from the current state the next state dur- 
ing every clock cycle. Many analog effects in such 
a system can be used in non-invasive attacks. Some 
examples are: 


e Every transistor and interconnection have a ca- 
pacitance and resistance that, together with fac- 
tors such as the temperature and supply voltage, 
determine the signal propagation delays. Due to 
production process fluctuations, these values can 
vary significantly within a single chip and between 
chips of the same type. 


e A flipflop samples its input during a short time 
interval and compares it with a threshold volt- 
age derived from its power supply voltage. The 
time of this sampling interval is fixed relative to 
the clock edge, but can vary between individual 
flipflops. 


e The flipflops can accept the correct new state only 
after the outputs of the combinatorial logic have 
stabilized on the prior state. 


e During every change in a CMOS gate, both the 
p- and n-transistors are open for a short time, 
creating a brief short circuit of the power supply 
lines [15]. Without a change, the supply current 
remains extremely small. 


e Power supply current is also needed to charge or 
discharge the load capacitances when an output 
changes. 


e A normal flipflop consists of two inverters and 
two transmission gates (8 transistors). SRAM 
cells use only two inverters and two transistors 


to ground one of the outputs during a write oper- 
ation. This saves some space but causes a signif- 
icant short-circuit during every change of a bit. 


There are numerous other effects. During careful 
security reviews of processor designs it is often nec- 
essary to perform detailed analog simulations and 
tests and it is not sufficient to just study a digital 
abstraction. 

Smartcard processors are particularly vulnerable 
to non-invasive attacks, because the attacker has full 
control over the power and clock supply lines. Larger 
security modules can be equipped with backup bat- 
teries, electromagnetic shielding, low-pass filters, 
and autonomous clock signal generators to reduce 
many of the risks to which smartcard processors are 
particularly exposed. 


2.2.1 Glitch Attacks 


In a glitch attack, we deliberately generate a mal- 
function that causes one or more flipflops to adopt 
the wrong state. The aim is usually to replace a sin- 
gle critical machine instruction with an almost ar- 
bitrary other one. Glitches can also aim to corrupt 
data values as they are transferred between registers 
and memory. Of the many fault-induction attack 
techniques on smartcards that have been discussed 
in the recent literature [11, 12, 16, 17, 18], it has 
been our experience that glitch attacks are the ones 
most useful in practical attacks. 

Wearecurrently aware of three techniques for cre- 
ating fairly reliable malfunctions that affect only a 
very small number of machine cycles in smartcard 
processors: clock signal transients, power supply 
transients, and external electrical field transients. 

Particularly interesting instructions that an at- 
tacker might want to replace with glitches are condi- 
tional jumps or the test instructions preceding them. 
They create a window of vulnerability in the process- 
ing stages of many security applications that often 
allows us to bypass sophisticated cryptographic bar- 
riers by simply preventing the execution of the code 
that detects that an authentication attempt was un- 
successful. Instruction glitches can also be used to 
extend the runtime of loops, for instance in serial 
port output routines to see more of the memory af- 
ter the output buffer [12], or also to reduce the run- 
time of loops, for instance to transform an iterated 
cipher function into an easy to break single-round 
variant [11]. 

Clock-signal glitches are currently the simplest 
and most practical ones. They temporarily increase 
the clock frequency for one or more half cycles, such 
that some flipflops sample their input before the new 
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state has reached them. Although many manufac- 
turers claim to implement high-frequency detectors 
in their clock-signal processing logic, these circuits 
are often only simple-minded filters that do not de- 
tect single too short half-cycles. They can be cir- 
cumvented by carefully selecting the duty cycles of 
the clock signal during the glitch. 

In some designs, a clock-frequency sensor that is 
perfectly secure under normal operating voltage ig- 
nores clock glitches if they coincide with a carefully 
designed power fluctuation. We have identified clock 
and power waveform combinations for some widely 
used processors that reliably increment the program 
counter by one without altering any other processor 
state. An arbitrary subsequence of the instructions 
found in the card can be executed by the attacker 
this way, which leaves very little opportunity for 
the program designer to implement effective coun- 
termeasures in software alone. 

Power fluctuations can shift the threshold volt- 
ages of gate inputs and anti-tampering sensors rel- 
ative to the unchanged potential of connected ca- 
pacitances, especially if this occurs close to the sam- 
pling time of the flipflops. Smartcard chips do not 
provide much space for large buffer capacitors, and 
voltage threshold sensors often do not react to very 
fast transients. 

In a potential alternative glitch technique that we 
have yet to explore fully, we place two metal needles 
on the card surface, only a few hundred micrometers 
away from the processor. We then apply spikes of 
a few hundred volts for less than a microsecond on 
these needles to generate electrical fields in the sil- 
icon substrate of sufficient strength to temporarily 
shift the threshold voltages of nearby transistors. 


2.2.2 Current Analysis 


Using a 10-15 2 resistor in the power supply, we can 
measure with an analog/digital converter the fluctu- 
ations in the current consumed by the card. Prefer- 
ably, the recording should be made with at least 
12-bit resolution and the sampling frequency should 
be an integer multiple of the card clock frequency. 
Drivers on the address and data bus often con- 
sist of up to a dozen parallel inverters per bit, each 
driving a large capacitive load. They cause a sig- 
nificant power-supply short circuit during any tran- 
sition. Changing a single bus line from 0 to 1 or 
vice versa can contribute in the order of 0.5-1 mA 
to the total current at the right time after the clock 
edge, such that a 12-bit ADC is sufficient to esti- 
mate the number of bus bits that change at a time. 
SRAM write operations often generate the strongest 


signals. By averaging the current measurements of 
many repeated identical transactions, we can even 
identify smaller signals that are not transmitted over 
the bus. Signals such as carry bit states are of special 
interest, because many cryptographic key scheduling 
algorithms use shift operations that single out indi- 
vidual key bits in the carry flag. Even if the status- 
bit changes cannot be measured directly, they often 
cause changes in the instruction sequencer or mi- 
crocode execution, which then cause a clear change 
in the power consumption. 

The various instructions cause different levels of 
activity in the instruction decoder and arithmetic 
units and can often be quite clearly distinguished, 
such that parts of algorithms can be reconstructed. 
Various units of the processor have their switching 
transients at different times relative to the clock 
edges and can be separated in high-frequency mea- 
surements. 


3 Countermeasures 
3.1 Randomized Clock Signal 


Many non-invasive techniques require the at- 
tacker to predict the time at which a certain instruc- 
tion is executed. A strictly deterministic processor 
that executes the same instruction c clock cycles af- 
ter each reset—if provided with the same input at 
every cycle—makes this easy. Predictable processor 
behaviour also simplifies the use of protocol reaction 
times as a covert channel. 

The obvious countermeasure is to insert random- 
time delays between any observable reaction and 
critical operations that might be subject to an at- 
tack. If the serial port were the only observable 
channel, then a few random delay routine calls con- 
trolled by a hardware noise source would seem suf- 
ficient. However, since attackers can use cross- 
correlation techniques to determine in real-time from 
the current fluctuations the currently executed in- 
struction sequence, almost every instruction be- 
comes an observable reaction, and a few localized 
delays will not suffice. 

We therefore strongly recommend introducing 
timing randomness at the clock-cycle level. A ran- 
dom bit-sequence generator that is operated with 
the external clock signal should be used to generate 
an internal clock signal. This will effectively reduce 
the clock frequency by a factor of four, but most 
smartcards anyway reduce internally the 3.5 MHz 
provided for contact cards and the 13 MHz provided 
for contact-less cards. 

Hardware random bit generators (usually the am- 
plified thermal noise of transistors) are not always 
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good at producing uniform output statistics at high 
bit rates, therefore their output should be smoothed 
with an additional simple pseudo-random bit gener- 
ator. 

The probability that n clock cycles have been exe- 
cuted by a card with a randomized clock signal after 
c clock cycles have been applied can be described as 


a binomial distribution: 
5 é c 
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So for instance after we have sent 1000 clock cy- 
cles to the smartcard, we can be fairly sure (prob- 
ability > 1 — 10~°) that between 200 and 300 of 
them have been executed. This distribution can be 
used to verify that safety margins for timing-critical 
algorithms—such as the timely delivery of a pay-TV 
control word—are met with sufficiently high proba- 
bility. 

Only the clock signals of circuitry such as the se- 
rial port and timer need to be supplied directly with 
the external clock signal, all other processor parts 
can be driven from the randomized clock. 

A lack of switching transients during the inactive 
periods of the random clock could allow the attacker 
to reconstruct the internal clock signal from the con- 
sumed current. It is therefore essential that the pro- 
cessor shows a characteristic current activity even 
during the delay phases of the random clock. This 
can be accomplished by driving the bus with ran- 
dom values or by causing the microcode to perform 
a write access to an unused RAM location while the 
processor is inactive. 


3.2. Randomized Multithreading 


To introduce even more non-determinism into 
the execution of algorithms, it is conceivable to de- 
sign a multithreaded processor architecture [19] that 
schedules the processor by hardware between two 
or more threads of execution randomly at a per- 
instruction level. Such a processor would have mul- 
tiple copies of all registers (accumulator, program 
counter, instruction register, etc.), and the combina- 
torial logic would be used in a randomly alternating 
way to progress the execution state of the threads 
represented by these respective register sets. 

The simple 8-bit microcontrollers of smartcards 
do not feature pipelines and caches and the entire 
state is defined only by a very small number of reg- 
isters that can relatively easily be duplicated. The 
only other necessary addition would be new machine 


instructions to fork off the other thread(s) and to 
synchronize and terminate them. Multithreaded ap- 
plications could interleave some of the many inde- 
pendent cryptographic operations needed in secu- 
rity protocols. For the remaining time, the auxiliary 
threads could just perform random encryptions in 
order to generate an realistic current pattern during 
the delay periods of the main application. 


3.3. Robust Low-frequency Sensor 


Bus-observation by e-beam testing becomes much 
easier when the processor can be clocked with only 
a few kilohertz, and therefore a low-frequency alarm 
is commonly found on smartcard processors. How- 
ever, simple high-pass or low-pass RC elements are 
not sufficient, because by carefully varying the duty 
cycle of the clock signal, we can often prevent the 
activation of such detectors. A good low-frequency 
sensor must trigger if no clock edge has been seen for 
longer than some specified time limit (e.g., 0.5 ys). 
In this case, the processor must not only be reset im- 
mediately, but all bus lines and registers also have to 
be grounded quickly, as otherwise the values on them 
would remain visible sufficiently long for a voltage- 
contrast scan. 

Even such carefully designed low-frequency detec- 
tors can quite easily be disabled by laser cutting or 
FIB editing the RC element. To prevent such simple 
tampering, we suggest that an intrinsic self-test be 
built into the detector. Any attempt to tamper with 
the sensor should result in the malfunction of the en- 
tire processor. We have designed such a circuit that 
tests the sensor during a required step in the nor- 
mal reset sequence. External resets are not directly 
forwarded to the internal reset lines, but only cause 
an additional frequency divider to reduce the clock 
signal. This then activates the low-frequency de- 
tector, which then activates the internal reset lines, 
which finally deactivate the divider. The processor 
has now passed the sensor test and can start normal 
operation. The processor is designed such that it 
will not run after a power up without a proper in- 
ternal reset. A large number of FIB edits would be 
necessary to make the processor operational without 
the frequency sensor being active. 

Other sensor defenses against invasive attacks 
should equally be embedded into the normal opera- 
tion of the processor, or they will easily be circum- 
vented by merely destroying their signal or power 
supply connections. 


3.4 Destruction of Test Circuitry 


Microcontroller production has a yield of typically 
around 95%, so each chip has to be thoroughly tested 
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Figure 8 The interrupted white line at the bot- 
tom of the cavity in this FIB secondary-electron im- 
age is a blown polysilicon fuse next to a test pad 
(MC68HC05SC2z processor). 


after production. Test engineers —like microprobing 
attackers—have to get full access to a complex cir- 
cuit with a small number of probing needles. They 
add special test circuitry to each chip, which is usu- 
ally a parallel/serial converter for direct access to 
many bus and contro] lines. This test logic is acces- 
sible via small probing pads or multiplexed via the 
normal I/O pads. On normal microcontrollers, the 
test circuitry remains fully intact after the test. In 
smartcard processors, it is common practice to blow 
polysilicon fuses that disable access to these test cir- 
cuits (Fig. 8). However, attackers have been able 
to reconnect these with microprobes or FIB editing, 
and then simply used the test logic to dump the en- 
tire memory content. 

Therefore, it is essential that any test circuitry is 
not only slightly disabled but structurally destroyed 
by the manufacturer. One approach is to place the 
test interface for chip n onto the area of chip n+ 1 
on the wafer, such that cutting the wafer into dies 
severs all its parallel connections. A wafer saw usu- 
ally removes a 80-200 ym wide area that often only 
contains a few process control transistors. Locat- 
ing essential parts of the test logic in these cut areas 
would eliminate any possibility that even substantial 
FIB edits could reactivate it. 


3.5 Restricted Program Counter 


Abusing the program counter as an address pat- 
tern generator significantly simplifies reading out the 
entire memory via microprobing or e-beam testing. 

Separate watchdog counters that reset the proces- 
sor if no jump, call, or return instruction is executed 
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for a number of cycles would either require many 
transistors or are too easily disabled. 

Instead, we recommend simply not providing a 
program counter that can run over the entire ad- 
dress space. A 16-bit program counter can easily 
be replaced with the combination of a say 7-bit off- 
set counter O and a 16-bit segment register S, such 
that the accessed address is S +O. Instead of over- 
flowing, the offset counter resets the processor after 
reaching its maximum value. Every jump, call, or re- 
turn instruction writes the destination address into 
S and resets O to zero. The processor will now be 
completely unable to execute more than 127 bytes 
of machine code without a jump, and no simple FIB 
edit will change this. A simple machine-code post- 
processor must be used by the programmer to insert 
jumps to the next address wherever unconditional 
branches are more than 127 bytes apart. 

With the program counter now being unavailable, 
attackers will next try to increase the number of it- 
erations in software loops that read data arrays from 
memory to get access to all bytes. This can for in- 
stance be achieved with a microprobe that performs 
a glitch attack directly on a bus-line. Programmers 
who want to use 16-bit counters in loops should keep 
this in mind. 


3.6 Top-layer Sensor Meshes 


Additional metallization layers that form a sen- 
sor mesh above the actual circuit and that do 
not carry any critical signals remain one of the 
more effective annoyances to microprobing attack- 
ers. They are found in a few smartcard CPUs such as 
the ST16SF48A or in some battery-buffered SRAM 
security processors such as the DS5002FPM and 
DS1954. 

A sensor mesh in which all paths are continu- 
ously monitored for interruptions and short-circuits 
while power is available prevents laser cutter or se- 
lective etching access to the bus lines. Mesh alarms 
should immediately trigger a countermeasure such 
as zeroizing the non-volatile memory. In addition, 
such meshes make the preparation of lower layers 
more difficult, because since the etch progresses un- 
evenly through them, their pattern remains visible 
in the layers below and therefore they complicate 
automatic layout reconstruction. Finally, a mesh on 
top of a polished oxide layer hides lower layers, which 
makes navigation on the chip surface for probing and 
FIB editing more tedious. 

The implementations of sensor meshes in fielded 
products however show a number of quite surpris- 
ing design flaws that significantly reduce the protec- 
tion (Fig. 9 and 10). The most significant flaw is 
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Figure 9: Escape route for imprisoned crypto bits: 
The ST16SF48A designers generously added this re- 
dundant extension of the data bus several micro- 
meters beyond the protected mesh area, providing 
easy probing access. 


. 


Figure 10: Every second line is connected to VCC 
or GND at one end and open at the other. Not all 
are used to supply lower layers and therefore some 
can safely be opened with a laser for probing access 
to the bus lines below. 


that a mesh breach will only set a flag in a status 
register and that zeroization of the memory is left 
completely to the application software. We noted 
in Section 2.1.4 that a common read-out technique 
involves severely disabling the instruction decoder, 
therefore software checks for invasive attacks are of 
little use. 

A well-designed mesh can make attacks by man- 
ual microprobing alone rather difficult, and more so- 
phisticated FIB editing procedures will be required 
to bypass it. Several techniques can be applied here. 
The resolution of FIB drilling is much smaller than 
the mesh line spacings, therefore it is no problem to 
establish contact through three or more metal layers 
and make deeply buried signals accessible for micro- 





Figure 11: A FIB was used here to drill a fine hole to 
a bus line through the gap between two sensor mesh 
lines, refill it with metal, and place a metal cross on 
top for easy microprobing access. 


probing via a platinum or tungsten pad on top of 
the passivation layer (Fig. 11). Alternatively, it is 
also possible to etch a larger window into the mesh 
and then reconnect the loose ends with FIB metal 
deposits around it. 


4 Conclusion 


We have presented a basis for understanding 
the mechanisms that make microcontrollers partic- 
ularly easy to penetrate. With the restricted pro- 
gram counter, the randomized clock signal, and 
the tamper-resistant low-frequency sensor, we have 
shown some selected examples of low-cost coun- 
termeasures that we consider to be quite effective 
against a range of attacks. 

There are of course numerous other more obvi- 
ous countermeasures against some of the commonly 
used attack techniques which we cannot cover in de- 
tail in this overview. Examples are current regula- 
tors and noisy loads against current analysis attacks 
and loosely coupled PLLs and edge barriers against 
clock glitch attacks. A combination of these together 
with e-field sensors and randomized clocks or per- 
haps even multithreading hardware in new processor 
designs will hopefully make high-speed non-invasive 
attacks considerably less likely to succeed. Other 
countermeasures in fielded processors such as light 
and depassivation sensors have turned out to be of 
little use as they can be easily bypassed. 

We currently see no really effective short-term 
protection against carefully planned invasive tam- 
pering involving focused ion-beam tools. Zeroiza- 
tion mechanisms for erasing secrets when tampering 
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is detected require a continuous power supply that 
the credit-card form factor does not allow. The at- 
tacker can thus safely disable the zeroization mecha~- 
nism before powering up the processor. Zeroization 
remains a highly effective tampering protection for 
larger security modules that can afford to store se- 
crets in battery-backed SRAM (e.g., DS1954 or IBM 
4758), but this is not yet feasible for the smartcard 
package. 
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Abstract 


In this paper, we aim to clarify some issues re- 
garding the deployment context of multiapplicative 
smart cards. We especially: deal with the trust re- 
lationships between the involved parties and the re- 
sulting constraints from a security point of view. 


We highlight a new security threat in a multiapplica- 
tive context and propose a new multilevel security 
model which allows to control precisely the informa- 
tion flows inside the card, and to detect illegal data 
sharing. 


Finally we illustrate all the proposed concepts on 
an multiapplicative example involving three appli- 
cations. 


1 Introduction 


Multiapplication smart cards are getting more and 
more attractive for numerous good reasons. Users 
are willing to reduce the number of cards in their 
wallets, issuers want to decrease the time-to-market, 
the development, infrastructure and deployment 
costs or to update/add applications after card is- 
suance. In addition multiapplication smart cards 
allow commercial synergies between partners and 
can lead to new business opportunities. A credit 
card with an electronic purse and a frequent flyer 
application is a classical example of a multiapplica- 
tion smart card. 


A few operating systems have been proposed to 
manage multiapplicative smart cards, namely Java 


Card!, Multos? and more recently Smart Card for 
Windows’. In this paper we will focus on Java Card 
and exhibit examples for this platform, but all the 
results can apply to any multiapplicative platform. 


Security is always’a big concern for smart cards, but 
the issue is getting more intense with multiapplica- 
tive platforms and post issuance code downloading. 
Of course, Java Card security or protection against 
aggressive applets have been discussed extensively, 
but we still lack a global security policy for mul- 
tiapplicative smart cards. We will show that this 
kind of policy must be more than the simple con- 
catenation of the security policy of all applications. 
Until now, this topic hasn’t been appropriately in- 
vestigated, probably because numerous issues con- 
cerning how those cards will be used remain unclear: 
which parties will cooperate? how? which of them 
will drive the scheme? etc. 


In this paper we first aim at clarifying those issues. 
Next, we show that there is a need for a card-wide 
security policy, mainly because of the existance of 
information sharing mechanisms between applets. 
Then, we propose a new security policy to deal with 
this need and show an example of how it could be 
used. We finish with limitations, potential exten- 
sions and related work. 


2 The multiapplication platform 


On a multiapplication platform, we usually find an 
operating system managing the card resources (like 
I/O, memory, random number generator, crypto en- 


1See http://java.sun.com/products/javacard. 
2See http: //www.multos.com. 
3See http://www.microsoft .com/smartcard. 
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gine...) and some applications (possibly loaded af- 
ter the card issuance) from various sources using the 
OS services. In addition, the OS ensures application 
segregation and provides mechanisms to allow con- 
trolled data sharing between applications. 


2.1 Which participants? 


Unlike single-application smart cards, multiappli- 
cation smart cards involve many participants. Of 
course, there are still an issuer and an end user, but 
additional third parties which can interact directly 
or not with the card are also involved. 


To separate precisely the actions of the participants 
we have defined two roles in addition to the usual 
issuer which is played by a unique authority: the 
application provider and the card operator. 


The application provider designs an application for 
the targeted card operating system and negotiates 
with the issuer for downloading its application in- 
side the card (before or after the card issuance). It’s 
the owner ofthe applet and applet’s data. Of course, 
the issuer itself will place some applications inside 
its card, and will play the application provider’s 
role. 


The card operator is an entity which can interact 
with the card either to use an application or to per- 
form administrative tasks. An administrative task 
can be anything from auditing the card or updating 
a key to downloading a new application. The in- 
teraction between the operator and the card can be 
direct (e.g. if the card is inserted in an ATM) or re- 
mote (e.g. through the Internet or a cellular phone 
network). It is likely that the application providers 
and the issuer will play the operator’s role as well. 
Conversely, an operator will probably be an appli- 
cation provider, even if it could be delegated to in- 
teract with an application of another provider. An 
applet can be designed to work with one operator 
(likely its owner) or more. In this case its behaviour 
could differ according to the operator. 


Coming back to the example of a credit card with a 
frequent flyer application, we can assume that the 
issuer will be a bank, which will also be the appli- 
cation provider and the operator of the credit ap- 
plet. An air travel company will be the provider 
and the operator of the loyalty applet. Some other 
companies can join the loyalty program and become 
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operators for the loyalty applet. 


2.2 How is it operated? 


The first and the simplest way to operate such a 
multiapplication platform is to keep it entirely un- 
der the control of the issuer. It will be the only 
authority responsible for the card and its integrity. 
All application providers must negotiate and agree 
with the issuer conditions and guidelines for down- 
loading their applications on the card. The issuer 
is granted all possible rights in the card and will 
enforce its policy during all the card life, as well 
as inspect applications carefully before download- 
ing them. In the rest of the paper we suppose this 
mode of operation as it seems to be the most likely 
in the forthcoming years. However, other ones like 
the two following could exist. 


One can imagine a second model where the end user 
buys a blank card from a manufacturer of its choice 
and plays the issuer’s role. Afterwards, it will ac- 
cept or buy from providers some applications for its 
card. The whole card will be (or should be) under 
its control. We do not consider this scenario as it 
is unclear if providers will accept to download their 
applications into cards for which they have no or few 
behaviour guarantees. Probably, this type of scheme 
will coexist with the first one, but for non security 
critical applications or for applications totally oper- 
ated by the end user. For example, a manufacturer 
of smart locks using smart cards, instead of keys, 
could propose to download its application on users 
cards. The users could decide to buy an ad hoc card 
or use an existing one to put the application driving 
the smart lock. 


A third type of scheme adds another role: certifica- 
tion authorities. Those authorities will audit issuers 
and their cards and will provide a certification which 
will guarantee that an issuer respects a given pol- 
icy. Based on this policy a provider as well as an 
end user will be able to decide if the issuer’s pol- 
icy complies with their requirements. An example 
of certification could be a “privacy awareness” label 
for issuers which respect the privacy rights of the 
users and do not leak private data outside the card. 
This is a refinement of our first scheme and we won’t 
focus on it in the following. 
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2.3. Which security policy? 


At first glance, it is easy to see that there are, at 
least, two separate security problems: the platform 
level security and the application level security. 


The first one (platform level security) concerns ap- 
plications segregation (this can be viewed as the 
classic OS security) as well as the quality of security 
services offered by the platform (e.g. correctness of 
the Java virtual machine including the verifier, tam- 
per resistance, cryptographic algorithms and post- 
issuance loading mechanism). This part is under 
the issuer’s responsibility. 


The second one (application security), is under the 
provider’s responsibility, but relies necessarily on 
the platform security. Moreover, the application 
should assume that the OS won’t be aggressive and 
will act as it is supposed to. Conversely, the OS 
doesn’t make any assumption about the application 
and should still work and protect the other appli- 
cations even if an aggressive or unsecure piece of 
code is loaded. However, one should note that even 
if this is technically perfectly acceptable, and if an 
unsecure application can’t threaten the platform or 
other application, the end users or potential cus- 
tomers could get confused by a break-in of an appli- 
cation and mixed up the platform security and the 
application security. To avoid this potential damage 
to its brand image, an issuer could enforce a min- 
imum security level for the applications loaded on 
its card by reviewing them or operating a scheme 
including some certification authorities. 


Apart from these two obvious security aspects, a 
third one must be addressed. All the difficulties 
arise from data sharing inside acard. Actually, most 
of multiapplication smart cards, in order to build 
cooperative schemes and optimize memory usage, 
allow data and service sharing (i.e. objects sharing) 
between applications. And beyond this point there 
is a need for a card-wide security policy concerning 
all the applications. A small example should make 
this point clearer. When an application provider 
A decides to share (or more probably to sell) some 
data with an application provider B, he will ask for 
guarantees that B won’t be able to resell those data 
or make them available world-wide. 


To address these problems two kinds of security poli- 
cies can be introduced: a discretionary one and a 
mandatory one. The applications will be in charge 


of defining their own discretionary security policy 
which could be enforced by the OS. For an example, 
in a Java card, an applet can decide to share some 
of its objects with a selective list of other applets. 
On this access control list basis, the OS will allow or 
deny access to the shared object by other applets. If 
we just consider a discretionary policy, nothing pre- 
vents an application B which could legally access 
an object of A (B has been granted from A to read 
the data) from copying the information into another 
object shared with C’. In this case the information 
is transfered from A to C even if C is not granted 
access the information from A. 


A mandatory security policy is necessary to solve 
the problem of re-sharing shared objects as pointed 
above. Actually none of the existing OS enforce 
such a policy. 


In this paper, we will discuss this last point and 
propose a security model, compliant with the re- 
quirements of safe data sharing and able to control 
the information flows inside the card. 


2.4 Which threat model? 


In the following we consider the threat of an insecure 
or malicious applet gaining legally some access to 
sensitive data (by a sharing mechanism of the OS) 
but resharing them illegally with a third party. 


The threat could be a commercial concern (as in 
the previous example) or privacy concern. This 
later case is especially important when dealing with 
health-care cards containing medical records or with 
loyalty cards containing marketing profiles. 


3 A new security model 


The security policy enforced by the OS should 
model the information flows between the applica- 
tions which, themselves, reflect the trust relation- 
ships between the participants of the applicative 
scheme. In this section we will start by studying 
the trust relationships, then the security model, and 
finally consider some implementation issues. 
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3.1 Trust relationships 


In the basic situation the only trust relationships are 
from everyone to the issuer, as there is no way for 
a participant to distrust the issuer. The platform 
OS is completely under the issuer’s control and is 
potentially able to read, write, create or modify ev- 
erything on it including the applications and their 
keys. 


In addition, some participants can trust other ones: 
sometimes because it is in fact the same entity which 
plays more than one role and sometimes because 
there is an agreement or a contract between the two. 


It should be noticed that the trust relationship is 
neither symmetric nor transitive: an entity wouldn’t 
like to trust someone only because one of its partners 
trusts it. This situation is not likely to change as co- 
operation in industry becomes something more com- 
plex and subject to daily change (one could speak 
about coopetition between companies as well as be- 
tween divisions inside a company). 


Figure 1 shows an example of trust relationships 
with four applications providers and three opera- 
tors. The issuer trusts no-one except OP1 and AP1 
which are two roles played by the issuer itself. We 
can see that AP1 trusts AP2 and AP2 trusts AP3 
which doesn’t mean that AP1 trusts AP3. 


We can also note that AP4 doesn’t operate its applet 
itself but relies on, and thus trusts, OP3 to do so. 


Now, it should be clear that a mandadory secu- 
rity policy must be enforced in a multiapplicative 
scheme which will allow or deny data flows between 
applications given the trust relationships. If an en- 
tity A trusts an entity B, this means that some in- 
formation could flows from A to B. We have chosen 
a classic multilevel security policy using a set of se- 
curity level modelling the trust relationships. 


3.2 The multilevel policy 


The multilevel security policy, first modelled in [2], 
uses a set of security levels with a complete lattice 
structure. A security level is associated to each sub- 
ject (an entity manipulating information) and each 
object (a piece of information but not an object in 
object-oriented programming sense) of the system. 
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The lattice structure implies an order relation on 
the set, and hence that the relation is transitive. 


The security rule states that a read (resp. write) ac- 
cess by a subject to an object is granted if and only 
if the level of the subject is greater (resp. lower) or 
equal to the object’s level. The classical example of 
a multilevel security policy is the document classi- 
fication inside a military organisation. In this case 
the set of security level is: { Unclassified, Confiden- 
tial, Secret, Top secret} with a usual order between 
the security levels. 


We will now consider how to map each entity and in- 
formation in a multiapplicative scheme to a security 
level. First of all we will create one level associated 
to the issuer and one associated to each application 
provider. If an operator and an application provider 
trust each other they will be represented by only one 
level. 


To establish a multilevel policy for a card with- 
out data sharing, one can choose a (non flat) lat- 
tice of security levels with one level for each ap- 
plication provider and an additional public level to 
complete the lattice. Figure 2 indicates the secu- 
rity level lattice corresponding to the example of 
figure 1, part (a), where an arrow represents an or- 
der relation between two levels. In this case, the 
only legal information flow is from a public level to 
the issuer through any role, but communication be- 
tween providers or operators is strictly prohibited 
except from AP4 to AP3 because AP4 trusts OP3 
and because OP3 and AP3 have been merged. 


To allow data sharing between entities, one cannot 
simply allow a new order relation between two roles 
as we cannot accept the transitivity effect of the 
order relation. As an example, if AP1 from our last 
example wants to share some data with AP2 and 
AP2 wants to share data with AP3, the security 
lattice of figure 2, part (b) is clearly inadequate. 
We recall that the trust relationship is not transitive 
and so AP1 does not want to share data with AP3 
which is possible with this solution through AP2. 


To solve this problem we propose that AP1 and 
AP2 agree on a data subset they want to share. 
Those data will be classified with a new level called 
AP1+AP2 placed in the security level lattice shown 
on figure 3. The same agreement will take place 
between AP2 and AP3 resulting in another level 
AP2+AP3. 
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Figure 1: Example of a trust relationship 
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Figure 2: Example of security level lattice without sharing (a) and with an unacceptable sharing (b). 


This technique can be refined if there is a need for 
sharing a subset of AP1+AP2 with AP3. We will 
create a new level called AP1+AP2+AP3 greater 
than the public level but lower than AP1+AP2 and 
AP2+AP3. 


3.3. Implementations issues 


To enforce the latter policy within a card (we con- 
sider here a Java Card), a lot of implementation 
issues should be considered. First of all, we should 
decide which data will be classified, and with which 
granularity. We should also consider the implemen- 
tation of security mechanisms which will enforce the 
policy. 


The classification of objects in object oriented lan- 
guage is a complex problem (see [5] for a recent dis- 
cussion on this subject), however, we can chose a 
simple strategy by assigning a security level to each 
object instance. In a given applet, the objects will 
be labelled with their provider’s level except if an 
object is shared, in which case, we will choose the 
level related to shared data. The authorized infor- 
mation flows in an applet will be from lower labelled 
objects to higher ones. 


Enforcing the security policy could be done dynam- 
ically by a reference monitor (part of the card OS) 
which will be called each time an object reference is 
used by the virtual machine or statically by check- 
ing the correctness of the information flows in an 
applet. The first solution would be too costly in 
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Figure 3: Example of security level lattice with acceptable sharing 


memory and execution time which are both critical 
in a smart card as we shoud tag each object with 
its level and check the validity of each read/write 
operation. 


The second solution has been studied for a long time 
(Denning pioneered this domain [6] and was followed 
by [8, 1, 11, 4]) and could be integrated to existing 
static verifier of Java bytecode. Using security level 
set with a lattice structure is a key point to guar- 
antee that the static analysis will terminate. 


Practically, this means that an applet provider will 
deliver its code to the issuer along with the security 
level of all the objects contained in it. The issuer 
will verify that the code and the declared levels of 
the objects comply with the other applets and their 
objects security levels. 


4 A real world example 


We present in this section the example of a multi- 
applicative healthcare card. This card is issued by 
a health insurance with an applet. This applet con- 
tains some administrative data including the social 
security number of the card holder. 


In addition, the user has joined the loyalty program 
of a drugstores chain and downloaded the corre- 
sponding applet. The drugstore applet can use the 
social security number and contains some admin- 
istrative data and, possibly, a few medical records 
(e.g. medication allergy). It also contains a loyalty 
part which maintains a loyalty points counter. 
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The third applet on the user’s card is a loyalty ap- 
plet of a sport centers chain which has an agree- 
ment with the drugstores chain and shares the loy- 
alty point counter with the drugstore applet. 


Figure 4 summarizes the information flow between 
the applets. 


The drugstore applet can read the social security 
number, but is not allowed to give it to other ap- 
plets. The security threat is the following: the 
drugstore applet can copy the social security num- 
ber from the healthcare applet to the loyalty point 
counter and broadcast it to applets allowed to read 
the counter. 


To face this threat, we propose a mandatory security 
policy using the security level lattice of figure 5. All 
the objects of the healthcare applet will be labelled 
with HC except the social security number labelled 
with SSN. The objects of the drugstore applet are 
labelled with the DS level except the loyalty point 
counter which is labelled with PTS. Finally, all the 
objects of the sport centers chain applet are labelled 
with SC. 


This way, if the drugstore applet copies the so- 
cial security number in one of its objects (labelled 
DS) and later in the loyalty point counter (labelled 
PTS), an illegal information flow will be detected 
as PTS is lower than DS and information can only 
flow from a lower level to a greater one. 


To be more complete, we should deal with the exter- 
nal world: the drugstore applet can exchange some 
data with an operator. The external software used 
by the operator should also be checked to verify that 
it doesn’t content a covert channel transfering infor- 
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Figure 4: Example of three applets sharing data 


Issuer 


| 


HC 


SC 


ee 


SSN 


PTS 


A 


Public 


Figure 5: Lattice of security levels for figure 4 applications 


mation from the DS level to the PTS level. 


As this software can be modified, the issuer can also 
ask the drugstore applet provider to encrypt the so- 
cial security number before sending it outside the 
card, 


5 Limitations and related work 


The limitations of our work clearly come from the 
communications with the external world. We are 
currently improving this point of the security model. 
We are also in the process of implementing static 
verifiers of applets as well as including declassifica- 
tion processes (e.g. when the data flow through a 
ciphering filter) in the security model. 


Some authors have already dealt with non- 
transitivity constraints in different contexts [10, 3], 
but we are not aware of a multilevel security policy 
applied to a smart card and its environment. A lot 
of papers dealing with classic Java Card security are 
available. We refer the reader to recent publications 
like [9] or [7] for a complete bibliography. 


6 Conclusion 


In this paper, we clarify some issues around the op- 
erating scheme of multiapplicative smart cards and 
highlight some new security threats. 


The proposed multilevel security model allows us 
to control precisely the information flows inside the 
card, and detect illegal data sharings. 


In a next step, analysing tools should be developed 
and provided to issuers which will be able to audit 
applets proposed by third parties for their cards. 
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Abstract 


We present a family of block ciphers that 
can be implemented very efficiently on cheap 
Smartcard processors. The ciphers use a 
very small amount of RAM and a reasonable 
amount of ROM. Both cipher execution and 
key setup/key change are very fast. The ci- 
phers resist theoretical and practical cryptan- 
alytic attacks and in their design timing and 
power analysis attacks have been taken into 
account. 


1 Introduction 


In many applications Smartcards are used 
as portable secure devices. For their secu- 
rity the applications make use of MAC gener- 
ation/verification and encryption/decryption 
using a block cipher. We present a family of 
block ciphers that are suited for this purpose. 
Additionally, all these ciphers can be used 
as efficient one-way function and the variants 
with block size of 196 bits or higher are ef- 
ficient compression function to form an iter- 
ated cryptographic hash function. The fam- 
ily is named after its first member that was 
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designed and published: Square [1]. 


Currently, the Square family consists of 
three ciphers: Square, with a block length 
and a key length of 128 bits; BKSQ with a 
block length of 96 bits and a variable key 
length (96, 144 or 192 bits); and Rijndael 
with a variable block length and key length 
(both can be independently specified at 128, 
192 or 256 bits). The three ciphers are de- 
signed to be secure against all known crypto- 
graphic attacks. For a treatment of crypto- 
graphic security and the design rationale we 
refer to [1, 2, 3]. This paper treats implemen- 
tation aspects and in particular those specific 
for Smartcards. 


In Section 2 we present the common ci- 
pher structure of the Square family. Section 3 
discusses the implementation of the ciphers 
on typical Smartcard processors. Section 4 
treats the features of the presented ciphers 
to thwart attacks that exploit typical weak- 
nesses of cipher implementations on Smart- 
cards. Section 5 lists concrete performance 
figures. 
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2 Cipher structure 


A Square cipher is an iterated block cipher: 
it consists of the repeated application of a 
round transformation that is parameterized 
by a round key. The round keys are derived 
from the cipher key by means of a key sched- 
ule. The block length is indicated by n, the 
cipher key length by m and the number of 
rounds by r. 


2.1 The round transformation 


The round transformation is composed 
of four invertible uniform transformations, 
called steps. These steps can be described 
most easily by thinking of the input as a rect- 
angular byte array. The dimensions of this 
byte array vary for the different members of 
the family, and depend on the block size. The 
four steps are described as follows (cf. Fig- 
ure 1). 


The diffusion step: Every byte is replaced 
by a linear combination of the bytes 
within the same column. The bytes 
are considered as elements in the field 
GF(2°). 


The dispersion step: A_ permutation of 
the bytes over different columns. This is 
done by shifting the rows of the byte ar- 
ray over different amounts, or by a trans- 
position of the byte array (for Square). 


The nonlinear step: A substitution of the 
bytes by means of a nonlinear lookup ta- 
ble. 


The round key addition: The bytes are 
EXORed with an n-bit round key. 


The choice for the operations in the dif- 
ferent steps has been influenced by our wish 
to make the cipher efficiently implementable 
on Smartcards. The key addition, the disper- 
sion and the nonlinear step all can be imple- 
mented using operations on individual bytes, 
the natural “unit” on an 8-bit processor. In 
the diffusion step, inter-byte diffusion has to 
be realised. On a 32-bit processor, this can 


be done by using operations like 32-bit ro- 
tations, multiplications, ..., but the use of 
these operations complicates Smartcard im- 
plementations. In the Square family, the dif- 
fusion step can be described as a matrix mul- 
tiplication (cf. Section 3). The coefficients of 
the multiplication matrix have been selected 
carefully to provide diffusion that is optimal 
in a very definite, mathematical sense, while 
at the same time allowing very efficient imple- 
mentation on standard Smartcard processors. 


2.2 The key schedule 


The round keys have length n and r+ 1 
round keys are required: one for every round 
and a final key addition. The key schedule 
can be thought to occur in two phases. 


Generation of the expanded key: The 
expanded key is initialized by taking 
the m-bit cipher key. It is expanded by 
iteratively attaching m-bit blocks that 
are computed from the previously at- 
tached block by means of an LFSR-like 
computation. This is repeated until the 
expanded key has length n(r + 1). 


Extraction of round keys: Round key i is 
taken from the expanded key by taking 
the i-th n-bit block. 


The LFSR computations in the key expan- 
sion ensure that any pair of different cipher 
keys result in a pair of expanded keys with 
a large Hamming difference. The addition of 
round constants removes symmetry between 
the rounds. This is necessary in order to 
provide resistance against related-key attacks 
and attacks where the cipher key is known, 
e.g., if the cipher is used as the compression 
function of a hash function. 


3 Specific Smartcard implemen- 
tation aspects 


In this section we discuss the implementa- 
tion of the cipher on 8-bit processors with a 
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Figure 1: Graphical illustration of some basic operations of the Square ciphers. 


limited amount of RAM and ROM available, 
i.e., typical Smartcard processors. 


3.1 The round transformation 


The round transformation can be imple- 
mented by serially performing the different 
steps. 


The nonlinear step consists of a table 
lookup operation that is the same for all 
input bytes. The 256-byte lookup table is 
hard-coded in the cipher program and the ta- 
ble lookup can be implemented with a sim- 
ple load accumulator instruction in indexed 
mode. The round key addition is imple- 
mented with the EXOR instruction. The byte 
dispersion step does not take dedicated in- 
structions but is embodied in the way input 
bytes are loaded and stored in the preced- 
ing/succeeding steps. These three steps can 
be implemented in the following way: the 
byte is loaded into the index register, an in- 
dexed load accumulator instruction is per- 
formed, the round key byte is EXORed and 
the accumulator is stored to the (hard coded) 


location. 


Implementing the diffusion step is less 
straightforward. It takes the computation 
of additions and multiplication in the field 
GF(28). Addition over this field corresponds 
to the readily available EXOR instruction. 
The multiplication factors are the elements 
of GF(2°) represented by byte values 1, 2 and 
3. The multiplication by these factors can be 
done as follows: 


e 1 is the identity in GF(2°) and multipli- 
cation by it does not require any compu- 
tation at all. 


Multiplication by 2 in the finite field 
could be implemented as a left shift, fol- 
lowed by a reduction. However, the exe- 
cution time and/or the power consump- 
tion pattern of a reduction depend on the 
value of the operand. If the MSB of the 
operand is 1, the reduction takes place, 
if 0, the reduction can be skipped. This 
can be done in constant time by execut- 
ing dummy instructions (e.g., NOP) in 
the case the reduction is skipped. How- 
ever, this gives rise to two different, se- 
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quences of operations. The operation 
can be implemented with a fixed series 
of instructions by implementing the mul- 
tiplication by 2 as a table lookup with a 
dedicated lookup table 2mult|-], that is 
defined as 


2mult[a] = 2-a. 


The fact that the execution time is inde- 
pendent of the argument makes this ta- 
ble lookup implementation timing attack 
resistant. We explain in Section 4 how it 
can be protected against power analysis. 


e Multiplication by 3 can be obtained by 
performing multiplication with 2 and 
adding (EXORing) the argument itself: 
3-a= (261) -a= 2mult[a] Ga. 


In Rijndael and Square the columns consist, 
of 4 bytes each and the diffusion step applied 
to a column can be described by a matrix 
multiplication, that is given by: 


outo 22 co a cd ing 
out, Al 1 2) Be in, 
outo, |) Wd) oh 22-83 ing 
i outs Sarl yea) ing 


This can be efficiently implemented as: 


P = ino Pin; Pine Pin3; 
outp = 2mult[ing @ in;]; outoS = p O ino; 
out; = 2multlin, @ ing]; out;® = p@in; 
outz = 2multl[ing @ ings]; oute® = p @ ing; 
outz = 2multling @ino|; outz® = p@ ins; 


This implementation takes only 15 EXORs 
and 4 table lookups per column. It requires 
temporary storage for 2 bytes: the variables 
p and ing (if the output buffer is equal to the 
input buffer). 


In BKSQ the columns consist of 3 bytes 
and the diffusion step is given by 


outg sia ae ing 
out, = 2 3 2 ¢ in, 
outs 2 2 ing 


This can be implemented with only 5 EXORs 
and a single table lookup per column and only 
one byte of temporary storage is needed. 


3.2 The inverse round transforma- 
tion 


The Square ciphers do not have the Feis- 
tel structure, like e.g. the DES. Whereas for 
Feistel ciphers the operation of the cipher can 
be inverted by simply reordering the round 
keys, this is not possible for the Square ci- 
phers. Therefore, if the inverse operation of 
the cipher has to be implemented, it is nec- 
essary to implement the inverse round oper- 
ation separately. 


The inverse of the round key addition is 
the same as the round key addition: EXOR 
with the round key. The inverse of the non- 
linear step is implemented like the linear step, 
but uses a different lookup table. The byte 
dispersion step is again embodied in the way 
input bytes are loaded and stored in the other 
steps. 


The inverse of the diffusion step consists 
of a multiplication with the inverse matrix. 
For Rijndael and Square, the inverse of the 
diffusion step is given by: 


outo E 9 D B ino 
out; | |B E 9 D iny 
out. | | DB E Q ing 
outs 9 DBE ing 


Here B, D and E denote hexadecimal values. 
It is easy to see that this multiplication will 
require more operations than the original dif- 
fusion step, namely 21 EXORS and 8 table 
lookups using only the previously defined ta- 
ble 2mult]-]. If additional tables are used, the 
performance loss can be reduced. The storage 
requirements do not increase. 


Note that most applications do not require 
the inverse operation of the cipher to be exe- 
cuted on the Smartcard. First of all, most of 
the applications use the cipher for the gen- 
eration and verification of MACs and as a 
one-way function in the generation of session 
keys. In the cases where encipherment is ac- 
tually used, the CFB or OFB mode can be 
used, where the inverse cipher is not used. 
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3.3 The key schedule 


In a Smartcard implementation, computing 
the expanded key in a single shot and storing 
it for use during the actual encryption, would 
require too much RAM. Therefore, the key 
expansion has been defined in such a way that 
it can be implemented in a cyclic buffer with 
a size no larger than the size of the cipher key. 
The expansion operation has been kept very 
simple and efficient to make fast just-in-time 
key generation possible. 


In the case that the cipher key length is 
equal to the block length, the round key is 
simply updated in between rounds. In the 
other cases, a small amount of additional se- 
quence control is required. All operations in 
the key update can be efficiently implemented 
using EXORs and table lookups. 


3.4 32-bit processors 


On a 32-bit processor, an efficient imple- 
mentation of the round transformation will 
use four large tables (1k each) that combine 
the effect of the nonlinear and the dispersion 
step. The tables will fit nicely in the cache of 
most modern 32-bit processors. 


The performance is independent of the 
value of the multiplication factors in the dis- 
persion step. The inverse operation of the ci- 
pher has the same performance as the forward 
operation, but uses a different set of tables. 


4 Smartcard-specific attacks 


Recently, several attacks have been demon- 
strated that exploit weaknesses of cipher 
implementations, rather than the inherent 
mathematical properties of the actual cipher 
[4]. These attacks exploit information such 
as timing and power consumption to obtain 
information on the cipher key or plaintext. In 
this section we will explain that the ciphers 
of the Square family lend themselves to im- 
plementations that provide resistance against 
this type of attack typical for Smartcards. 


If programmed as explained in the previ- 
ous section, the cipher execution consists of a 
series of instructions that is completely fixed: 
there are no conditional branches whose exe- 
cution depends on the cipher key and input. 
This thwarts the following attacks: 


Timing attack: This attack extracts 
key/plaintext information from the 
CPU time consumed by the cipher. 
For the Square ciphers the CPU time 
is independent of the cipher key and 
plaintext. 


Simple power analysis: This attack ex- 
tracts key/plaintext information by ob- 
serving the power consumption during 
the cipher computation. Different CPU 
instructions have different power con- 
sumption and this attack allows to deter- 
mine whether one or another conditional 
branch is taken in a computation. For 
the Square ciphers the series of instruc- 
tions is fixed. 


A more powerful attack is differential 
power analysis. This attack exploits the fact 
the power consumed by the CPU not only de- 
pends on the instruction that is executed, but 
also on the values of the operands. It com- 
bines the application of cryptanalytic tech- 
niques, statistics and power analysis. Basi- 
cally, it allows the determination of the value 
of individual bits of intermediary computa- 
tion results of the cipher by an attacker that 
does not even need to know the sequence of 
instructions. The basic flaw that is exploited 
is that the power consumed by an instruction 
depends on the values of the bits that are 
handled by the command. To thwart these 
attacks, two mechanisms are proposed: 


scrambling: To complicate the exploitation 
of power consumption bias, e.g., by us- 
ing programming tricks, such as inser- 
tion of a variable amount of NOPS, or 
better, unnecessary instructions in be- 
tween rounds. Scrambling can be applied 
reasonably independent from the cipher 
structure. 


curing: To make the power consumption of 
the relevant instructions used in a cipher 
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implementation much less dependent on 
the value of the treated bits. One plau- 
sible way to cure instructions is by the 
introduction of symmetry. For example: 
if a bit is stored in (loaded from) RAM, 
also store (load) its complement. If two 
bits are EXORed, execute all four differ- 
ent combinations: a@b,a@b,a@b, a@b). 
Typically, additional hardware has to be 
introduced for every sensitive instruc- 
tion. Therefore it is an advantage to 
have few different instructions that han- 
dle key- or plaintext-dependent bits. 


The instructions that handle key- or plain- 
text dependent bits in our implementations 
of the ciphers of the Square family are: 


e EXOR with accumulator, direct address- 
ing; 


e store accumulator, direct addressing; 
e load accumulator, direct addressing; 


* load accumulator, indexed addressing 
(offset + index register) 


These are only four instructions. Most other 
modern ciphers [5] use an instruction set that 
is substantially larger, due to the use of arith- 
metic operations. Moreover, the balancing 
of arithmetic operations is likely to be more 
complicated than the balancing of the EXOR. 
It can be seen that there is arithmetic addi- 
tion in the indexed addressing. However, if 
the lookup tables are positioned at physical 
addresses that are a multiple of 256, the ad- 
dress computation can be reduced to a mere 
concatenation of index and offset. Obviously, 
this implies a modification of the ALU hard- 
ware. 


5 Performance 


We implemented the Square ciphers on two 
different types of microprocessors that are 
representative for Smartcards in use today. 
These implementations have been optimized 
towards minimal RAM usage and execution 
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time while guaranteeing a fixed execution 
time. Table 1 shows that besides the storage 
of the current round ‘key and the intermedi- 
ate ciphertext, only four bytes of RAM are 
used. The numbers compare very favorably 
with the figures for the other AES candidate 
algorithms. 


The timings given include the key setup 
and algorithm setup time. Only the for- 
ward operation of the ciphers have been im- 
plemented, backwards operation is expected 
to be slower because the inverse of the diffu- 
sion step cannot be implemented as efficiently 
(cf. Section 3.2). The inverse diffusion step is 
between 1.5 and 2 times slower than the orig- 
inal diffusion step. Since the diffusion step is 
dominant in the execution of the ciphers on a 
Smartcard, about the same performance loss 
can be expected for the full cipher. 


The implementations on the Motorola 
68HC08 microprocessor have been done us- 
ing the 68HC08 development tools by P&E 
Microcomputer Systems, Woburn, MA USA, 
the IASM08 68HC08 Integrated Assembler 
and the SIML8 68HC08 simulator. No op- 
timization of code length has been attempted 
for this processor. Execution time, code size 
and required RAM for a number of imple- 
mentations are given in Table 1 (1 cycle = 1 
oscillator period = 0.25 psec). 


Rijndael has also been implemented on the 
Intel 8051 microprocessor, using 8051 De- 
velopment tools of Keil Elektronik: Vision 
IDE for Windows and dScope Debug- 
ger/Simulator for Windows. Execution time 
for several code sizes is given in Table 2 (1 
cycle = 12 oscillator periods = 1 psec). 


6 Availability 


Several implementations of Square 
in C and Java are available from the 
URL  http://www.esat.kuleuven.ac.be/ 
~rijmen/square. 


More information on Rijndael and a refer- 
ence implementation are available from the 
URL  http://www.esat.kuleuven.ac.be/ 
“rijmen/rijndael. 
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Cipher Code size Execution time 
(Key, block length) | (bytes) (msec) 


BKSQ(96,96) [| 900 | 28 i 6500 
Square(128,128) | 919 6800 
Rijndael(128,128) | 919 |36 ~~! 3390 


and ces 
Rijndael(192,128) | 1170__| 44 | _10780 
Rijndael(256,128) | 1135 52 12490 


Required RAM | Number of cycles 
















Table 1: Code size, required RAM and execution time for the square ciphers in Motorola 
68HC08 Assembler. 


(Key, block length) || Code size 


i Number of cycles es time 
P| iby tes) (msec) 













1065 i 
(128,128) 3744 





1016 3168 ny 
(192,128) | 1125 4512 | 4.5 


(256,128) ws 5221 5.2 











Table 2: Code size and execution time for Rijndael in Intel 8051 assembler. 
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Abstract 


We identify the need for a portable format for storage of 
user credentials (certificates, keys) on cryptographic 
tokens such as integrated circuit cards (IC cards). Given 
this need, a recent proposal in the area, RSA 
Laboratories’ PKCS #15 is described and compared with 
previous and related work. 


1 Background and Motivation 


Cryptographic tokens, such as Integrated Circuit Cards 
(IC cards or “smart cards”), are capable of providing a 
secure storage and computation environment for a wide 
range of user credentials such as keys, certificates and 
passwords. Because of this, it is widely recognized (cf. 
[2], [15] and [25]) that they offer great potential for 
secure identification of users of information systems 
and electronic commerce applications. For a general 
introduction to IC cards and their use, cf. [3] or [17]. 


Unfortunately, the use of these tokens for authentication 
and authorization purposes is hampered by the lack of 
interoperability at several levels (cf. [1]). First, the 
industry lacks standards for storing a common format of 
digital credentials (keys, certificates, etc.) on them. This 
has made it difficult to create applications that can work 
with credentials from a variety of technology providers. 
Attempts to solve this problem in the application 
domain invariably increase costs for both development 
and maintenance. They also create a significant problem 
for end-users since credentials are tied to a particular 
application running against a particular application- 
programming interface to a particular hardware 
configuration. 


Second, mechanisms to allow multiple applications to 
effectively share digital credentials have not yet reached 
maturity. While this problem is not unique to 
cryptographic tokens — it is already apparent in the use 
of certificates with World Wide Web browsers, for 
example ~— the limited room on many tokens together 
with the consumer expectation of universal acceptance 
will force credential sharing on credential providers. 
Without agreed-upon standards for credential sharing, 


acceptance and use of them both by application 
developers and by consumers will be muted. 


To optimize the benefit to both the industry and end- 
users, it is important that solutions to these issues be 
developed in a manner that supports a variety of 
operating environments, application programming 
interfaces, and a broad base of applications. Only 
through this approach can the needs of constituencies be 
supported and the development of credentials-activated 
applications encouraged, as a cost-effective solution to 
meeting requirements in a very diverse set of markets. 


The purpose of the work we describe in this paper, 
PKCS #15 [19], has therefore been to: 


e Enable interoperability among components running 
on various platforms (platform neutral); 


e Enable applications to take advantage of products 
and components from multiple manufacturers 
(vendor neutral); 


e Enable the use of advances in technology without 
rewriting application-level software (application 
neutral); and 


e Maintain consistency with existing, related 
standards while expanding upon them only where 
necessary and practical. 


By fulfilling these objectives, PKCS #15 is a first step 
to ensure that token-holders will be able to use their 
cryptographic tokens to electronically identify 
themselves to any application regardless of the 
application's token interface. The ultimate goal is a 
situation in which a token-holder can use any card from 
any manufacturer to identify himself or herself to any 
application running on any platform. 


2 Related Work 
21 DC/SC 


“Digital Certificates on Smart Cards,” DC/SC [1], was a 
collaborative effort mainly between CertCo, Litronics 
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and GemPlus, initiated to facilitate the interoperability 
of applications using digital certificates stored on IC 
cards. DC/SC concentrated on the problem of finding all 
digital certificates stored on a particular user’s IC card. 
The proposed solution was to add an extra elementary 
file at the root level on the card system (ISO/IEC 78 16- 
4 compliant IC cards were assumed), in which 
applications would read and write information about 
known certificates on the card. 


The objective of DC/SC was very similar to PKCS 
#15’s objective: To enhance portability of user 
credentials stored on IC cards. The main difference was 
perhaps that DC/SC only concentrated on certificates 
and did not intend to create a new card application for 
general credential storage. DC/SC eventually folded its 
work into the SEIS specification. 


2.2 SEIS 


SEIS, Secured Electronic Information in Society, is a 
Sweden-based non-profit association. One of SEIS’ 
most important projects has been to specify an 
Electronic Identity IC card with an Electronic ID 
Application. This includes means for secure, electronic 
authentication of the cardholder; generation of legally 
acceptable Digital Signatures; and support for session 
key exchange, e.g. protection of message 
confidentiality. The intention is that these functions will 
be implemented using “off the shelf’ IC cards. The 
usage is intended for security services both within, as 
well as between, organizations. 


So far, two specifications have been developed which 
relate closely to PKCS #15: SEIS S1 [21] and SEIS S4 
[22]. SEIS S1 is a detailed definition of an electronic 
identity card application. It specifies where and how 
information about certificates, keys and PINs shall be 
stored on a compliant IC card. SEIS S4 is a profile that 
puts some further restrictions on the format and the size 
of used keys. 


Being a pure electronic identification application based 
on public-key technology, SEIS Sl and S4 do not 
contain support for any other key types than private 
RSA keys and supports only X.509 [10] certificates. 
Furthermore, there is no support for general security- 
related data objects. 


Although it is more generic, PKCS #15 is a continuation 
of the SEIS work. The concept of a standardized, 
generic IC card format is a cornerstone of the SEIS 
architecture. 


2.3. The WAP consortium 


WAP, the Wireless Application Protocol Forum [12], is 
a consortium of companies involved in creating a de- 
facto standard for wireless information and telephony 
services on digital mobile phones and other wireless 
terminals. A part of this work is to enable secure 
identification of subscribers to these services. For this 
reason, subscribers will be issued IC cards (SIM cards, 
“Subscriber Identification Module”), which are to be 
inserted in phones, and the WAP Identity Module 
Specification (WIM) [26] has therefore basically the 
same objectives as PKCS #15. The current draft 
version, v0.7 is in fact designed as a PKCS #15 profile. 


2.4 Other related work 


This section contains a survey of other specification-, 
standardization- and product-efforts, related to PKCS 
#15. 


2.4.1 The PC/SC specification 


The Interoperability Specification for ICCs and 
Personal Computer Systems [20], or PC/SC for short, is 
a workgroup formed by leading IC card and personal 
computer vendors such as GemPlus, Schlumberger and 
Microsoft. The intention was to develop a specification 
that could facilitate the interoperability necessary to 
allow Integrated Circuit Card (ICC) technology to be 
effectively utilized in the PC environment, and in a 
manner which would “support both existing and future 
IC card-based applications” [20]. 


Part 8 of the specification, “Recommendations for ICC 
Security and Privacy Devices” [16], does mention 
(without binding requirements) a few formats for 
storage of information, but other than this, the PC/SC 
specification does not deal with the contents of the IC 
card itself. Hence, credential portability is not covered 
by the PC/SC specification. The intention with PC/SC is 
that each platform the user accesses with his IC card 
will have a service provider interface installed for that 
particular card. The drawback of this is that it forces 
cardholders to choose particular cards and vendors. One 
additional problem with this architecture is that it relies 
on the IC card vendor for providing both the card 
interface and the functional interface. An alternative 
solution would have been to separate this into two 
layers: one handling the card interface and one handling 
the format interface. With separated layers and an open 
card format standard, a generic PKCS#15 layer could be 
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installed and card layers added for each card the 
user/customer has. A user could choose any card type, 
have it personalized by any application vendor which 
personalizes cards in accordance with PKCS#15 and use 
it on any PC/SC system which has a PKCS#15 format 
service provider installed and, in addition, a service 
provider for that particular card type. 


2.4.2 OpenCard Framework 


The OpenCard Framework (OCF) [23] provides a 
common programming interface for both the smart card 
reader and the application on the card. By basing the 
architecture on Java technology, the intention is to 
receive enhanced portability and interoperability. The 
version 1.1 specification also enables, through an 
adaptation layer, interaction with existing PC/SC‘ 1.0 
supported reader devices. 


Although the OCF simplifies the task for application 
builders, and has made explicit the distinction between a 
card layer and a format layer, it does not deal with the 
problem of credential portability. The 
ApplicationManagement layer is a rudimentary service 
layer in principle only supporting application listing and 
selection. OCF applications — still need explicit 
knowledge of the location and structure of files 
contained in card applications (card layout in OCF 
terminology). Therefore, a cardholder will still be 
restricted to use his proprietary-formatted card only on 
those platforms, for which a card-application aware 
OCF application has been installed, which probably will 
be within a particular domain. 


2.4.3 The JavaCard specification 


The JavaCard specification [24], developed by Sun 
Microsystems, defines a subset of the Java language for 
use on IC cards and other embedded systems. The 
intention is to simplify card-application development by 
offering a familiar high-level programming language 
interface to developers of card-side applications. By 
implementing a version of the Java Virtual Machine on 
top of existing IC card operating systems, applications 
become portable and easier to develop. 


The specification does not deal with card layouts or 
information formats, instead it defines a framework for 
creating applications. Even though it is possible to 
implement PKCS #15 on a JavaCard, it would probably 
be more natural to define a generic ‘Electronic ID’ 
JavaCard application (cardlet in — established 
terminology). The JavaCard specification of such an 


application would instead of specifying internal file 
formats define the command interface used to store and 
retrieve security-related information as well as to 
execute cryptographic commands. 


2.4.4 MultOS 


MULTOS [13] is another attempt to simplify card-side 
application development and portability of card-side 
applications. MULTOS is a card operating system that 
implements an Application Abstract Machine (AAM). 
The intention is that by using services offered by the 
AAM, application programmers do not need specific 
knowledge about underlying hardware. 


Similar to the JavaCard case, it probably makes more 
sense to define a standard “MULTOS Electronic ID 
application”, specifying the command interface rather 
than actual file formats in the MULTOS case. 


3 An Overview of PKCS #15 


Having described the problem background and related 
work, we now proceed to describe the standard itself, 
and requirements that have influenced its design. 


3.1 Design Goals 
Token neutral 


e Inorder not to favor any particular brand or type of 
IC card, PKCS #15 has been designed in such a 
way that the standard can be implemented on any 
IC card with basic ISO/IEC 7816 compatibility. For 
example, no assumptions about IC card commands 
except those defined in ISO/IEC 7816-4 [4] have 
been made. In fact, it should even be possible to 
implement it on memory cards and software tokens. 


e In order to support memory cards and tokens that 
do not have built-in support for encryption, 
provision has been made to allow stored objects to 
be encrypted and/or integrity-protected. 


e Finally, in order to support tokens which do not 
have the notion of “files”, PKCS #15 has been 
designed to allow all information to be stored in 
one contiguous block. 


Standards compliant 


e In order to be aligned with ISO/IEC 7816-5 [5] and 
ISO/IEC 7816-6 [6], the information format (as 
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seen by an interface communicating with the card) 
has been defined in ASN.1 [9]. 


e The format allows storage of information concepts 
such as security environments, defined in ISO/IEC 
FCD 7816-8 [7]. 


e The “object-oriented” approach chosen for PKCS 
#11 [18], treating keys, certificates and other data 
as objects with attributes and values, has been 
adopted for PKCS #15 as well. It has a proven 
record and eases PKCS #11-based 
implementations. 


Self-contained 


e Given an IC card with a PKCS #15 application on 
the chip, in order to be able to use the card for 
secure identification, it must be possible for a host- 
side application to find out which algorithms, keys 
and certificates that are present on the card. This 
led to the inclusion of TokenInfo files and Object 
Directory files, see Section 3.2. 


e Applications also need to know how objects are 
protected, and procedures for accessing them. They 
also need to know which objects that are possible to 
update and which are not. This requirement has 
been met by introducing appropriate security 
attributes and authentication objects that can be 
referenced from protected objects like keys. 
Authentication objects are stored in Authentication 
Object Directory files, see Section 3.2. 


Flexible and modular structure 


e It should not be necessary to store all PKCS #15- 
relevant objects in the PKCS #15 application. 
Sometimes a certificate may already exist on the 
token when the PKCS #15 application is stored on 
it, for example. Therefore, an extra level of 
indirection has been introduced, giving the PKCS 
#15 application the ability to refer to objects like 
certificates stored in other dedicated files (or at 
other places like LDAP accessible directories). 


e When dealing with IC cards, the problem of card 
tearing (cf. [3], pp. 175-176) has to be considered. 
This means that every update needs to be as atomic 
as possible, and if interrupted due to premature card 
removal, should not leave the card in an 
inconsistent state. This led to the decision to make 
the file structure record-oriented and modular. 
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e Since it is anticipated that PKCS #15 will be used 
in a number of applications for different purposes 
and with different security requirements, no 
particular requirements in terms of access 
restrictions have been mandated; an appendix 
giving general recommendations has been 
provided, however. This appendix also builds on 
ideas expressed in ISO/IEC CD 7816-9 [8]. 


3.2 File Structure and Motivations 


The content of the PKCS #15 dedicated file is a bit 
dependent on the type of IC card and its intended use, 
but the following file structure is likely to be the most 
common, especially when the card is intended to be 
used for identification/authentication purposes: 


Figure 1: Contents of DF(PKCS15) 


The contents and purpose of major elementary files in 
the PKCS #15 directory are described below. 


The Object Directory File, ODF 


The mandatory elementary file ODF (Object Directory 
File) consists of pointers to other elementary files 
(PrKDFs, PuKDFs, SKDFs, CDFs, DODFs and 
AODFs), each one containing a directory over PKCS 
#15 objects of a particular class. The ODF therefore has 
a record-oriented structure, with each record merely 
being a pointer to another directory file. 


Cryptographic Key Directory Files, PrKDFs, SKDFs 
and PuKDFs 


These elementary files can be regarded as directories of 
keys known to the PKCS#15 application. PrKDFs 
contain information about private keys, PuKDFs contain 
information about public keys and SKDFs contain 
information about secret (symmetric) keys. They are all 
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optional, but at least one file of a particular kind must 
be present on an IC card which contains keys (or 
references to keys) of that particular kind, known to the 
PKCS#15 application. The files contain general key 
attributes such as labels, key usage restrictions, 
identifiers, type of algorithm, key size (if applicable), 
etc. Furthermore, they contain pointers to the keys 
themselves. 


Certificate Directory Files CDFs 


These elementary files can be regarded as directories of 
certificates known to the PKCS#15 application. They 
are optional, but at least one CDF must be present on an 
IC card which contains certificates (or references to 
certificates) known to the PKCS#15 application. They 
contain general certificate attributes such as labels, 
identifiers, certificate type, etc. They also contain 
pointers to the certificates themselves. When a 
certificate contains a public key corresponding to a 
private key that is also known to the PKCS #15 
application, the certificate and the private key will share 
a common identifier. This simplifies look-up of the 
private key given the certificate and vice versa. 


Trusted Certificate Directory Files 


These elementary files have the same syntax as ordinary 
CDFs, but only contain trusted certificates. In the 
context of PKCS #15, “trusted certificates” are CA 
certificates not possible to be replaced by the 
cardholder. 


Authentication Object Directory Files AODFs 


These elementary files can be regarded as directories of 
authentication objects (e.g. PINs) known to the 
PKCS#15 application. They are optional, but at least 
one AODF must be present on an IC card, which 
contains authentication objects restricting access to 
PKCS#15 objects. They contain generic authentication 
object attributes such as (in the case of PINs) allowed 
characters, PIN length, PIN padding character, etc. 
Furthermore, they contain pointers to the authentication 
objects themselves (e.g. in the case of PINs, pointers to 
the directory in which the PIN file resides). 
Authentication objects are used to control access to 
other objects such as keys. Each object in this file has a 
unique reference number, which is used for cross- 
reference purposes from e.g. the PrKDFs to link keys 
with authentication objects. 


Data Object Directory Files, DODFs 


These files can be regarded as directories of data objects 
(other than keys or certificates) known to the PKCS#15 
application. They are optional, but at least one DODF 
must be present on an IC card which contains such data 
objects (or references to such data objects) known to the 
PKCS#15 application. They contain general data object 
attributes such as identification of the application to 
which the data object belongs, whether it is a private or 
public object, etc. In addition to this, they contain 
pointers to the data objects themselves. 


The TokenInfo file 


The mandatory TokenInfo elementary file contains 
generic information about the token as such and its 
capabilities, as seen by the PKCS #15 application, e.g. 
supported algorithms, token serial number, etc. In order 
to save some storage space, provisions for cross- 
referencing algorithm information from the PrKDFs, 
PuKDFs and SKDFs to this file has been made. 


4 An Example Application 


PKCS #15 v1.0 contains a profile of the information 
format for electronic identification purposes. This 
profile specifies the use of two private keys, two user 
certificates and two PINs. Each private key is to be 
protected with a separate PIN and also linked to a 
corresponding certificate. The intention is that the 
cardholder use one key (and associated PIN) for general 
authentication purposes and key exchanges, and the 
other key (and associated PIN) strictly for non- 
repudiation (or digital signature) purposes, like signing 
documents. 
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Figure 2: Logical file structure of PKCS #15’s Electronic ID profile 


If some 3"-party application-specific data is added to a 
token containing the Electronic ID profile of PKCS 
#15’, the token will be useable not only for general 
identification purposes but for that 3"-party 
application’s purposes as well. An example of this is 
the profile suggested in WIM [26], in which the 
cardholder will be able to use the card not only as a 
cellular phone card enabling phone calls and related 
services, but also enabling Internet access from any 
PKCS #15 aware application. If PKCS #15 is well 
received, it is likely that similar cases will occur in a 
number of other environments, like on-line banking, as 
secure credit cards, etc. 


5 Summary and Future Work 


PKCS #15 was announced in September 1998. Shortly 
thereafter, the SEIS specifications were adopted as 
national standards in Sweden. At the same time, the 
WAP Forum submitted its first Identity Module draft 
containing an IC card file structure. Coordinating with 
and using experiences from these efforts as well as 
other ones has been and continues to be an important 
part of this project. The first official version of PKCS 
#15 is expected to be available in April 1999. 


The current draft version of the standard does not deal 
at all with more advanced IC cards like JavaCards or 
MULTOS cards. As mentioned in this paper, since 
these cards are able to store and execute more complex 


: Preferably in the form of PKCS#15 Data Objects. 


applications, the equivalent of PKCS #15 in_ this 
environment would probably be a “standard electronic 
ID application,” defining a service interface rather than 
an information format. 


The current lack of standardization of security-related 
commands for IC cards presents a more serious 
problem with regard to interoperability. In order to 
achieve interoperability with PKCS #15, an application 
needs not only to have a format layer implementing 
support for the PKCS #15 format, but also a card 
adaptation layer, implementing support for proprietary 
security-related commands set for a range of IC cards. 
If or when a set of such commands becomes formally 
standardized and adapted by IC card vendors, this card 
adaptation layer would become superfluous. ISO/IEC 
7816-8 [7] is intended to solve the problem of 
standardization in this area, and hopefully card vendors 
will adjust to this standard in a timely manner. 


ISO/IEC JTC1 SC17 has recently discussed [11] a 
possible new work item defining an Electronic ID 
Application for identification cards. While the 
prospects for such a work item remain unclear, PKCS 
#15 could clearly be one candidate for this format. 
PKCS #15 has also been suggested as the card format 
for the national identity IC card in Finland [14]. 
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Abstract 2 Remotely Keyed Encryption 


Remotely keyed encryption supports fast encryption A remotely keyed encryption scheme (RKES) dis- 

on a slow smart card. For the scheme described here, tributes the computational burden for a block cipher 

even a smart card without a builtin encryption func- with large blocks between two parties, a host and 

tion, would do the job, e.g., a signature card. a re e Figure 1 gives a general description of an 
R : 


1 Introduction plaintext | 


Many security relevant applications store secret keys 
on a tamper-resistant device, a smart card. Pro- 
tecting the valuable keys is the card’s main purpose. 
Typically, smart cards are slow. Using them for key- 
dependent operations such as en- and decrypting in- 
herently must be slow as well, right? Wrong, para- 
doxically there is still a way of doing fast encryption 
using a slow card. 

Often, smart cards are designed to support authen- 
tication or digital signatures instead of encryption. 
In this paper, we concentrate on the RaMaRK pro- 
tocol, theoretically based on (pseudo)random map- 
pings. Paradoxically enough: The RaMaRK proto- 
col does not require the smart card itself to support 
encryption — support for hash functions, as built into 
many signature cards, is sufficient. In a world with Figure 1: A generic RKES 
lots of restrictions on the import, export or usage of 
encryption tools and much less restrictions regard- 
ing authentication or signature tools, this can be an We think of the host being a computer under the 
important property. risk of being taken over by an adversary, while the 





ciphertext 
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card can be a smart card, protecting the secret key. 
We do not consider attacks to break the tamper- 
resistance of the smart cards itself. The host knows 
plaintext and ciphertext, but only the card is trusted 
with the key. 

An RKES consists of two protocols: the encryption 
protocol and the decryption protocol. Given a B-bit 
input, either to encrypt or to decrypt, such a protocol 
runs like this: The host sends a challenge value to the 
card, depending on the input, and the card replies a 
response value, depending on both the challenge value 
and the key. 

The notion of remotely keyed encryption is due to 
Blaze [2]. Lucks [8] pointed out some weaknesses of 
Blaze’s scheme and gave formal requirements for the 
security of RKESs: 


(i) Forgery security: If the adversary has controlled 
the host for g—1 interactions, she cannot produce 
q plaintext /ciphertext pairs. 


(ii) Inversion security: An adversary with (legiti- 
mate) access to encryption must not be able do 
decrypt and vice versa. 


(iii) Pseudorandomness: The encryption function 
should behave pseudorandomly for someone nei- 
ther having access to the card, nor knowing the 
secret key. 


While Requirements (i) and (ii) restrict the abilities 
of an adversary with access to the smart card, Re- 
quirement (iii) is only valid for outsider adversaries, 
having no access to the card. If an adversary could 
compute forgeries or run inversion attacks, she could 
easily distinguish the encryption function from a ran- 
dom one. 

It is theoretically desirable, that a cryptographic 
primitive always appears to behave randomly for ev- 
eryone without access to the key. So why not re- 
quire pseudorandomness with respect to insider ad- 
versaries? In any RKES, the amount of communica- 
tion between host and card should be smaller than 
the input length, otherwise the card could just do 
the complete encryption on its own. Since (at least) 
a part of the input is not handled by the smart card, 
and, for the same reasons, (at least) a part of the 


output is generated by the host, an insider adversary 
can easily decide that the output generated by herself 
is not random. 

In 1998, Blaze, Feigenbaum, and Naor [3] found an- 
other way to define the pseudorandomness of RKESs. 
Their formal definition is quite complicated. Is is 
based on the adversary A gaining direct access to the 
card for a certain amount of time, making a fixed 
number of interactions with the card. When A has 
lost direct access to the card, the encryption function 
should appear to behave randomly, even for A. Re- 
cently, Lucks [9] described an “accelerated” RKES, 
which satisfies the security requirements of Blaze, 
Feigenbaum and Naor, but is significantly more ef- 
ficient. Note that both schemes acutally require the 
card to execute encryption function, while this pa- 
per deals with remotely keyed encryption using non- 
encrypting smart cards. 

Theoretically, one could define an encryption func- 
tion based on random mappings and hence adapt the 
schemes of [3, 9] for the use of non-encrypting smart- 
cards. Such a construction could be based on using 
Luby-Rackoff ciphers [6], or on one of the many re- 
finements of them, such as the one in [7]. In practice, 
the resulting RKE-scheme would be quite inefficient, 
though. 


3 RaMaRK Encryption scheme 


In this section, we describe the Random Mapping 
based Remotely Keyed (RaMaRK) Encryption 
scheme, which uses several independent instances of 
a fixed size random mapping f : {0,1}° -— {0,1}°. 
In practice, one uses pseudorandom functions? in- 
stead of truly random ones. The scheme is provably 
secure if its building blocks are, i.e., it satisfies 
requirements (i)—(iii) above, see [8]. Note that b 
must be large enough—performing close to 26/2 
encryptions has to be infeasible. We recommend 
to choose b > 160. By “®” we denote the bit-wise 
XOR, though mathematically any group operation 
would do the job as well. 


lif f is “pseudorandom”, it is infeasible to distinguish be- 
tween f and a truly random function - except if one knows the 
secret key. 
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We use three building blocks: 


1. Key-dependent (pseudo-)random mappings f; : 
{0,1}® —> {0,1}. 


2. A hash function H : {0,1}* —> {0,1}. 


has to be collision resistant, i.e. it has to be 
infeasible to find any t,u € {0,1}* with u A t 
but H(u) = H(t). 


3. A pseudorandom bit generator (ie. a “stream 
cipher”) S' : {0,1}° —+ {0,1}*. We restrict our- 
selves to S : {0,1} —+ {0,1}#-?°, 


If the seed s € {0,1}° is randomly chosen, the 
bits produced by S(s) have to be indistinguish- 
able from randomly generated bits. 


In addition to pseudorandomness, the following 
property is needed: If s is secret and attackers 
choose ti, tg,... € {0,1}° with t; At; fori Aj 
and receive outputs S(s ®t ), S(s ®t), ..., it 
has to be infeasible for the attackers to distin- 
guish these outputs from independently gener- 
ated random bit strings of the same size. Hence, 
such a construction behaves like a random map- 
ping {0,1}° —> {0,1}%-?°, thought it actually 
is a pseudorandom one, depending on the secret 
s. 


Based on these building blocks, we realize a remotely 
keyed encryption scheme to encrypt blocks of any size 
B > 3b, see figure 2. 








Figure 2: The RaMaRK encryption protocol 


3.1 RaMaRK Encryption Protocol 


We represent the plaintext by (P,Q, R) and the ci- 
phertext by (A,B,C), where (P,Q, R),(A,B,C) € 
(Oh? OTe tO 28S Bor the protocol 
description we also consider intermediate values 
TU Vik Ye 2 e410, Ly andy 64101228, 

The encryption protocol works as follows: 


1. Given the plaintext (P,Q, R), the host sends P 
and Q to the card. 


2. The card computes 
U = fi(P) @Q and T = f2(U) @ P, 


and sends 
X = f(T) eU 


to the host. 
3. The host computes 
I=S(X)@Rand Y = H(), 


sends 
Z=X OY 


to the card, and computes 


C=S(Z) el. 


4. The card computes 
V = fa(T) © Z, 
and sends the two values 
A= fs(V) @T and B = fs(A) BV 


to the host. 


3.2 


In order to decrypt the ciphertext (A, B,C), we need 
the following protocol: 


RaMaRK Decryption Protocol 


1. Given the plaintext (A, B,C), the host sends A 
and B to the card. 
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2. The card computes 
Y= fe(A) ® B and T= fs(V) @ A, 


and sends 
Z=fa(T) OV 


to the host. 
3. The host computes 
I=S(Z)@C and Y = H(I), 


sends 
X=ZO0Y 


to the card, and computes 


R=S(X)@1. 


4. The card computes 
U=f3(T) OX 
and sends the two values 
P= fo(U) @T and Q =f, (P) OU 
to the host. 


One can easily verify that by first encrypting any 
plaintext using any key, then by decrypting the result 
using the same key, one gets the same plaintext again. 


3.3. Remark 


Neither the amount of communication between host 
and card, nor the amount of work on the size of the 
card depend on the block size B of the full cipher. 
Thus, if B is not too small compared to the parameter 
b, which defines the size of the blocks sent to the 
card, the RaMaRK scheme is efficient. The card itself 
operates on 26 bit data blocks, and both 30 bit of 
information enter and leave the card. In practice, 
b > 160 gives a high level of security, while B can be 
huge. 
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4 Extended Security Require- 
ments 


Regarding the RaMaRK scheme, the authors of [3] 
pointed out that an adversary A who had access to 
card and lost the access again, can later chose spe- 
cial plaintexts where A can predict a part of the ci- 
phertext. This makes it easy for A to distinguish 
between RaMaRK encryption and encrypting ran- 
domly.” Thus, according to the definition of [3], the 
RaMaRK scheme is not pseudorandom. 


We believe that it is possible to extend the Ra- 
MaRK scheme to make it pseudorandom even in the 
sense of [3], i.e., with respect to insider adversaries. 
So far, this is an open problem. Note that all schemes 
in [3] are pseudorandom as defined there, but depend 
on pseudorandom permutations (i.e., block ciphers) 
— and thus are designed for smart cards with builtin 
encryption. 


5 Implementation of Building 
Blocks on the Host 


On the side of the host, we need standard crypto- 
graphic primitive operations, which can easily be im- 
plemented or found in a cryptographic function. 


5.1 Hash Functions. 


To combine the big block of data with the small 
blocks in the card we need a collision-free hash func- 
tion. The calculation is performed on the host, so 
we can simply chose a well-tested hash fuction like 
SHA-1[5] or RIPE-MD160[4]. Both produce a 160-bit 
output, which seems to provide sufficient security. 


?The intermediate value X only depends on the (P, Q)-part 
of the plaintext, and the encryption of the R-part only depends 
on X. If A chooses a plaintext (P,Q, R), having participated 
before in the encryption of (P,Q, R’), with R # R’, the adver- 
sary A can predict the C-part of the ciphertext corresponding 
to (P, Q, R) on her own. 
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5.2 Pseudo Random Bitgenerators. 


In [8] the use of a stream cipher was suggested. We 
can also use a well-tested block cipher in the OFB or 
CFB mode (E.g. CAST-5 performs very fine even on 
small packets [10]). 


6 Keydependent  Pseudoran- 
dom Mappings on the Card 


In this section we want to discuss how to realise 
Pseudo Random Mappings (PRM) with an Non- 
Encrypting smartcard. For the purposes of this pa- 
per, we suggest to use hash-based Message Authenti- 
cation Codes (MACs) as tools. We specifically recom- 
mend the HMAC-construction from Bellare, Canetti, 
and Krawczyk (1], which is provably secure. 

Note that a cryptographic hash function is defined 
to take a bit-sting of an arbitrary length as input, to 
produce a fixed-size bit-string as output. (In addi- 
tion to this, it also has to satisfy some cryptographic 
security criteria.) 


6.1 Using a Hash-Based MAC to re- 
alize PRMs 


Trusting in a well-studied dedicated hash function, 
such as SHA-1 or RIPEMD-160, to realize a key- 
dependent Message Authentication Code provides a 
couple of advantages for our scheme: 


e Cryptographic hash functions have been well 
studied. 


e Cryptographic hash functions are usualy faster 
than encryption algorithms. 


e MACs based on SHA-1 or RIPE-MD160 mostly 
provide 160-bit output. So even birthday attacks 
which need 2®° operations are infeasible. 


e Some hash-based MACs are provably secure if 
the underlying hash is secure. 


e The proof of security for some MAC construc- 
tions can rely on quite weak assumptions on the 


hash function’s security, compared to the stan- 
dard assumptions for hash functions. Thus, even 
if the hash function we use is broken and inse- 
cure for signatures or other applications, it may 
still be infeasible to break the HMAC instanti- 
ated with this hash function. 


e In many countries, it is more easy to export or 
import an authentication tool, such as a signa- 
ture smart card, than to export or import an 
encrypting device, such as a smart card with a 
builtin encryption function. 


6.2 HMAC: A Construction for Hash- 
Based MACs 


HMAC [I] has the advantage that we can use any 
cryptographic hash function H as blackbox. The only 
restriction on is the following: 71 is assumed to 
be an iterative hash function. That means, it inter- 
nally uses a compression function, iteratively taking 
a fixed-size value as input (say, 512 bit), to produce 
a smaller-sized output (e.g., 160 bit). Most crypto- 
graphic hash functions known today are iterative. If 
needed, one can easily define a secure iterative hash 
functions based on a secure non-iterative one. 

The HMAC function is defined like this: 


HMAC, (x) := H(K @ opad||H(K @ ipad||s)) 


with ipad := Ox36 repeated 64 times and ipad := 
Ox5C repeated 64 times’, K is generated by append- 
ing zeros to the end of K to create a 64 byte string‘. 
(Note that the specific values of ipad and opad are 
relevant for actually implementing HMACs without 
creating incompatible versions, but with respect to 
the security of HMACs, one mainly has to keep in 
mind ipad # opad.) 

In [1] a proof is given, that the HMAC construction 
is secure against collision attacks and forgery attacks. 


2The number of repetitions may actually change, depending 
on the input size of the underlying compression function. Most 
present-day hash functions, including the well-studied SHA-1 
and RIPEMD-160, use a compression function with an input 
size of 512-bit (i.e., 64 byte). 

4This size of 64 byte also changes with the input size of the 
compression function 
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As usual in ‘present-day cryptography, the proof of 
security is based on some unproven but reasonable 
assumptions. The weaker such assumptions are, the 
stronger is the proof. It is thus remarkable, that the 
proof in [1] only makes very weak assumptions on 
the security of the underlying hash function (and no 
assumptions otherwise). 

Consider selecting a hash function H for the 
HMAC construction, i.e., instantiating the HMAC 
construction with #1. Of course, this has to be done 
with great care. But it is the state-of-the-art in to- 
day’s cryptography, that no one can rule out com- 
pletely that this hash function H is later found to be 
insecure, e.g., collisions for H are found. A collision 
consists of two bit-strings « # y with the same values, 
i.e, H(x) = H(y). Such collisions do exist of course, 
but if it is feasible to actually find such collisions, this 
would be deathly for using 1 in the context of signa- 
tures. On the ohter hand, due to the weak assump- 
tions on H the HMAC-construction requires, even a 
collision-prone hash function H could still satisfy the 
security requirements for HMACs, and HMACs in- 
stantiated with H could be secure, nevertheless. 
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Abstract 


We describe our design and implementation of 
smartcard integration with Kerberos V5. Au- 
thentication is among the most important ap- 
plications for smartcards and is one of the crit- 
ical requirements for computer security. By 
augmenting Kerberos V5 with tamper-resistant 
hardware, we enhance the security of Kerberos 
V5 and offer a potential “killer application” 
leading to wider adoption of smartcard tech- 
nology. 


1 Introduction 


Smartcards are a rapidly emerging technology 
that have received much attention both from 
industry and academia. Smartcards can make a 
significant impact on current computer systems 
because of their inherent security and mobility. 


According to market researcher Dataquest, the 
smartcard market will grow from 544 million 
units in 1995 to 3.4 billion units by 2001. How- 
ever, the vast majority of smartcards are used 
in Europe; 90 percent of worldwide smartcard 
shipments went to Europe in 1995. Only 2 per- 
cent were shipped to the Americas [4]. 


Smartcards are not popular in the United 
States because there is no “killer application” 
for smartcards here. Smartcards were intro- 
duced to Europe by government telecommuni- 
cations monopolies in the form of phone cards, 


but the telecommunications industry in the US 
is private and decentralized. 


These cultural and economic differences are 
common to other smartcard applications preva- 
lent worldwide, such as health care and bank- 
ing. In addition, credit cards are more success- 
ful in the US than in Europe, in part due to 
online verification, which is universally avail- 
able in the US. This keeps fraud rates low 
— reportedly 0.07% [11] — which allows card 
issuers to indemnify customers for any loss 
over 50 USD. Consequently, issuers, customers, 
and merchants are equipped and satisfied with 
magstripe cards and readers, which feature low 
cost and broad familiarity [3]. 


The information technology business sector 
might provide the killer application for the 
smartcard industry in the United States be- 
cause the demand for secure computer environ- 
ments is huge and growing. ‘There is an increas- 
ing fear of hackers attacking sensitive informa- 
tion on the Internet. Smartcards can provide 
a secure authentication system when combined 
with sound authentication protocols, and can 
significantly improve computer system security 
wherever authentication plays a critical role in 
the computer security scheme, 7.e., everywhere. 


At the University of Michigan, smartcards are 
already deployed and used for storing a small 
amount of cash. Thus, we have a good setting 
for extending the deployment of smartcards in 
the computer environment: 


e Students and faculty are familiar with us- 
ing smartcards. 
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e An infrastructure is well established, e.g., 
many vending machines and shops have 
smartcard readers. 


e There is a serious security problem that 
can be solved by integrating smartcards 
into the computer environment. 


e University technologists, especially at the 
Center for Information Technology Inte- 
gration (CITI), have skill sets and re- 
sources to develop smartcard applications. 


The goal of our project is to develop, build, 
and deploy a smartcard-integrated computer 
environment. We want to provide a smartcard 
in everyone’s pocket that handles computer 
authentication, computer profiles, electronic 
cash, banking, identification, course registra- 
tion, paying rents, submitting resume, copy 
machines, etc. [6]. 


The centrally administered computing environ- 
ment at the University of Michigan is pro- 
tected by Kerberos, the most widely used net- 
work authentication protocol [21, 13]. Kerberos 
is also key to the security infrastructure at 
MIT (where Kerberos was invented), Cornell, 
Carnegie-Mellon, and Stanford, as well as in 
mainstream commercial product offerings from 
IBM, Microsoft, and Oracle. 


Kerberos suffers from some inherent security 
pitfalls, principally its reliance on passwords 
selected by users. In recent years, CITI staff 
have used password guessing attacks [6, 7] on 
the University of Michigan Kerberos servers 
with (disappointing) success, quickly obtaining 
thousands of passwords on each occasion. ‘To 
improve the security of Kerberos and the in- 
frastructure it protects, we intend to replace 
passwords with randomly generated Kerberos 
keys stored on a smartcard. 


The remainder of this paper is organized as 
follows. In Section 2, we describe why and 
how smartcards can enhance the security of 
Kerberos. In Section 3, we explain the pro- 
tocol we use to integrate Kerberos with smart- 
cards. Section 4 contains implementation de- 
tails for those who want to port our program 


to other operating systems or to use other types 
of smartcards. (Readers who are not interested 
in implementation details may want to skip the 
section.) Performance is evaluated in Section 
5. Section 6 discusses related work and smart- 
cards we have examined. Future directions are 
described in Section 7, followed by concluding 
remarks in Section 8. 


2 How can smartcards help Ker- 
beros? 


Bellovin and Merritt enumerate problems of 
Kerberos that “are not solvable without em- 
ploying special-purpose hardware, no matter 
what the design of the protocol.” [2] The prob- 
lems include: 


e Need for secure encryption device 
e Need for secure key storage 


e Dictionary attack on passwords 


We explain these problems, and describe coun- 
termeasures that take advantage of strong se- 
curity feature of smartcards, 


2.1 Need for secure encryption de- 
vice 


In the Kerberos protocol, a user key, Ky, is 
shared between a user and a Key Distribution 
Center (KDC), a trusted third party. K, is 
derived from a password: a workstation reads 
the password from a user, converts it to Ky, 
and uses it to decrypt a ticket granting ticket 
(TGT), an initial credential in Kerberos. The 
protocol is shown in Figure 1. 


1) When a user attempts to login to a work- 
station, the workstation sends a request to the 
KDC. 2) KDC generates a TGT, encrypts it 
with K,,, and sends it back to the workstation. 
3) The workstation asks the user for a pass- 
word, hashes it into key ,,, and uses the key 
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1) username 


. 2) {TGT}xu 
password eee eee 


3) Decrypt TGT 


Figure 1: Kerberos authentication proto- 
col without a smartcard 






User 


to decrypt the TGT. If the TGT decrypts prop- 
erly, the user is authenticated and is allowed to 
login. 


In this protocol, K,, is exposed to two parties, a 
user and a workstation. A key memorized by a 
user can be vulnerable because she can tell it to 
another person, or an adversary might “shoul- 
der surf” it when she types it. If she is using a 
window manager, her keystrokes may even be 
snooped remotely without her knowledge. 


A key in a workstation can be vulnerable if the 
workstation is not securely protected or cannot 
be trusted for other reasons. For example, if 
an adversary can scan the entire physical mem- 
ory of the workstation, he can obtain the key. 
Along the same lines, if someone has admin- 
istrative access rights to the workstation, it is 
straightforward to install a rogue login program 
in the workstation that stores a user’s password 
in the adversary’s directory. (This is called a 
Trojan horse attack.) 


To solve these problems, it is desirable to de- 
crypt the TGT outside a workstation. There- 
fore, an external encryption device is required. 


2.2 Need for secure key storage 


Kerberos stores some keys in computers, e.g., 
session keys in a workstation and user keys in 
KDC. However, typical computers cannot store 
information securely. Information in a com- 
puter system is stored either in memory or on a 
hard disk, but neither is sufficiently secure. A 
secret stored on a hard disk is hard to protect 
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because: 


e A powerful adversary can access (read and 
write) it. 


e It is usually backed up in mass storage de- 
vices, which may lack sufficient physical or 
cryptographic protection. 


A secret in memory is also hard to protect be- 
cause : 


e Memory can be physically scanned by a 
powerful adversary. 


e It may be paged out to hard disks, which 
can be scanned. 


Therefore, secure storage outside a workstation 
and KDC is an important goal. 


2.3 Dictionary Attack 


When a user chooses a poor password, the de- 
rived user key K,,, is subject to dictionary at- 
tack. Dictionary attack is performed as follows: 


1. Create a list of common words, names, etc. 
2. Derive keys from the words in the list. 
3. Obtain a <plaintext, ciphertext> pair. 


4. Decrypt the ciphertext with the derived 
keys. 


5. If the plaintext is recovered correctly, the 
key used for decryption is revealed. 


For example, if the password is a short English 
word, an adversary can try all English words 
in the dictionary and quickly discover the pass- 
word. 


Kerberos is vulnerable to dictionary attack be- 
cause: 
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1. It is a password-based authentication pro- 
tocol. 


2. It easily gives up a _ <plaintext, 
ciphertext> pair to the adversary. 


Test runs of dictionary attack in the University 
of Michigan Kerberos realm have yielded pass- 
words for more than 5% of the user accounts, 
i.e., over 4,000 accounts [6].! 


To solve problem (2), pre-authentication is in- 
troduced in Kerberos V5. The Kerberos au- 
thentication protocol with pre-authentication 
is depicted in Figure 2. 










Kerberos 
Koc [xu] 


{TGT}xu 









1) ie 
3) 
password, Vorkstation 
[xu 
User 
4) Decrypt TGT 


Figure 2: Kerberos authentication proto- 
col with pre-authentication 


In this scenario, the KDC ensures that the 
client knows Ky, before issuing a TGT. 1) 
When the client requests the TGT, it sends 
a username and a timestamp encrypted with 
K,. 2) If the KDC can successfully decrypt 
with K,, and recover the username and a valid 
timestamp, it is sure that the client knows 
K,. If not, the KDC assumes someone is im- 
personating the client to obtain a <plaintext, 
ciphertext> pair and rejects the request. 3) 
After pre-authentication, the KDC sends the 
TGT encrypted by K, to the workstation and 
the protocol continues as depicted in Figure 1. 


Pre-authentication prevents an adversary from 
getting a <plaintext, ciphertext> pair just by 
requesting it, and thus raises the bar of se- 
curity to the adversary. However, the adver- 
sary can still eavesdrop a network to obtain a 
<plaintext, ciphertext> pair. Also note that 
it is very easy for the adversary to recognize a 


1The most common password was “love”. Go figure. 
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plaintext because it includes well known entries 
such as a user name and a realm name. 


As long as Kerberos uses passwords for secure 
information, dictionary attack cannot be solved 
completely. Therefore, it is desirable to replace 
passwords with randomly generated bits stored 
in tamper-resistant hardware [17]. 


A smartcard is an ideal device to solve the 
problems outlined here. The countermeasures 
are described in the next section. 


3 Design 


In this section, we describe a method intended 
to enhance the security of Kerberos. It takes 
advantage of a smartcard to solve the problems 
stated in Section 2. 


From the discussion in Section 2, our design 
goals are: 


e Use randomly generated bits for Ky. 


We can prevent dictionary attack by us- 
ing a random key instead of a user chosen 
password. However, we then require a way 
for users to store their keys, as it is impos- 
sible (and insecure!) to expect anyone to 
remember a random string of any substan- 
tial size. 


e Store a user key in a smartcard. 


A smartcard can serve as an external 
key store because it is designed to be 
tamper-proof with restricted communica- 
tion mechanisms. 


e Decrypt TGT in a smartcard. 


A smartcard can perform decryption as an 
external encryption device because it has 
DES en(de)cryption mechanisms.” 


e Do not modify KDC. 


2Or claims to. Many smartcards claim to offer DES 
but they in fact do not. We discuss this further in 
Section 6.2 
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If KDC must be modified to implement the 
smartcard augmentations, then our efforts 
will offer enhanced security in our local 
Kerberos realm, but nowhere else. We also 
want our improvements to enhance the se- 
curity of Kerberos realms beyond our ad- 
ministrative control. 


3.1 Protocol 


Figure 3 shows our Kerberos authentication 
protocol with a smartcard. Steps 1) and 2) 
are identical to the original protocol (Figure 1). 
3) When the workstation receives the TGT, it 
does not decrypt it by itself. Instead, it sends 
the TGT to a smartcard. 4) The smartcard 
then decrypts the TGT, and returns the TGT 
in plaintext to the workstation. 5) If the work- 
station confirms that the decrypted TGT is cor- 
rect, the protocol is finished and the user is au- 
thenticated. 


User 






1) username 


2) {TGT}xu 





4) Decrypt TGT 


Figure 3: Kerberos authentication proto- 
col with a smartcard 


The protocol satisfies the goals we stated 
above; TGT is decrypted in the smartcard, Ky, 
never leaves the smartcard, K,, can be random 
bits, and KDC is not modified.? Furthermore, 
use of a smartcard obviates the requirement for 
preauthetication; even if jplaintext, ciphertext; 
pairs are obtained through network snooping, 
the keys are selected at random, so are immune 
to dictionary attack 


3JIn fact, KDC in Kerberos V5-1.0.5 must be mod- 
ified by one line to run the protocol due to a bug in 
Kerberos. However, this modification will not be nec- 
essary in later version of Kerberos. We discuss it in 
Section 4.1. 


Kerberos 
KDC 


4 Implementation 


We implemented the smartcard integrated Ker- 
beros protocol described in Section 3. We now 
detail the modifications we made to the Ker- 
beros library, the DES library, and the Ker- 
beros client. 


TGT decryption is implemented with two 
smartcards: 


e STARCOS version 2.1 from Giesecke & 
Devrient 


e Cyberflex Access from Schlumberger 


Both cards provide native czpher block chain- 
ing (CBC) for long messages. (A Kerberos V5 
TGT is over 200 bytes long.) Cyberflex Access 
is a Java programmable card. STARCOS is not 
programmable. 


The development platform is OpenBSD-2.4 on 
Pentium 400MHz PC. The code base is Ker- 
beros version 1.0.5 released by MIT. 


4.1 Adding an encryption system in 
Kerberos library 


Kerberos V5 uses a look-up table to provide for 
easy replacement and development of encryp- 
tion systems [12]. The look-up table associates 
an encryption type to cryptographic functions, 
such as encryption, decryption, and checksum 
functions, and data structures, such as a key 
structure. It is simple to add a new encryption 
system entry by adding an entry to the look-up 
table. 


There are several encryption system types de- 
fined in the RFC[12] and implemented in Ker- 
beros V5-1.0.5 including: 


e¢ No encryption 


e DES in CBC mode with a CRC-32 check- 
sum (des-cbc-crc) 
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e DES in CBC with MD5 (des-cbc-md5) 


We created a new encryption system, 
DES in CBC with MDd with a smart- 
card (des-cbc-md5-sc). We added a new 
entry des-cbc-md5-sc in the look-up table. 
The entry is defined in des_md5.c (Figure 4). 


krb5_cryptosystem_entry 
mit_des_md5_sc_cryptosystem_entry { 
EncryptionType ENCTYPE_DES_CBC_MD5_SC; 


DecryptionFunc mit_des_md5_sc_decrypt_func(); 


// Other members are identical to des-cbc-md5 


Figure 4: Smartcard cryptosystem entry 


mit_des_md5-sc_decrypt_func() is a new 
function that uses a smartcard for decryption. 


The other members of the entry are not modi- 
fied. 


Although the default hash method in Kerberos 
V5-1.0.5is CRC, implementation of des-cbc-cre 
in Kerberos V5-1.0.5 has a bug. In the Ker- 
beros 5 specification, the initialization vector 
(IV) of DES-CBC mode is defined to be 0 [12]. 
However, des-cbc-crc uses the key as the IV. 
This error can not be fixed easily because Ker- 
beros 5 is already deployed widely and several 
commercial offerings use the key as the IV as 
well. The G&D smartcard cannot use the key 
as an IV without passing it as an argument to 
the card, which defeats our goal of eliminating 
the key on the workstation. 


To our relief, des~cbc-md5 uses 0 as the IV, 
complying with the RFC. Rumor hasit that the 
next version of Kerberos will use des-cbc-md5 
by default. 


4.2 Modifying DES library 


mit_des_md5-sc-decryptfunc() calls the 
DES-CBC encryption funetion in f-cbe.c. 
We created a new D£S_CBC function 
mit_des_cbc_sc_encrypt() that calls a DES 
function in a smartcard instead of a Kerberos 
DES library. STARCOS version 2.1 can handle 
up to 112 bytes in one command. The TGT, 
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whose length is approximately 200 bytes, 
is divided into two pieces, decrypted in a 
smartcard piece by piece, and combined into 
one TGT in the workstation. 


The specific commands, or APDUs in ISO 
7816-4, sent to the smartcard are as follows. 
(Readers not familiar with smartcard APDUs 
are advised to consult the ISO 7816-4 specifica- 
tion [8] or Guthery and Jurgensen’s book [5].) 


e Send “decrypt” APDU with 112 (0x70) 
bytes of encrypted data. 


Ox80 Oxf8 Ox81 Ox81 Ox70 data .. 


e Send “get response” APDU to upload 112 
bytes of plaintext data. 


0x00 OxcO 0x00 0x00 0x70 


We repeat these steps with the second half of 
the TGT, using an IV taken from the first half. 


4.3 Modifying kinit 


In the authentication function get_in_tkt(), 
an encryption system can be chosen as an ar 
gument. We modified kinit.c so that it does 
not request a password from the user, and spec- 
ified encryption type des—cbc-md5-sc instead 
of des-cbc-md5. 


5 Performance Evaluation 


Here we evaluate the performance of our Ker- 
beros modifications. 


5.1 Performance Evaluation 


We ran the authentication protocol described 
in Section 3.1 by executing the modified kinit 
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program five times and logged salient perfor- 
mance data. The authentication time fluctu- 
ates within a relatively small range (about 0.1 
sec.), averaging 1.14 sec. with STARCOS and 
2.96 sec. with Cyberflex. STARCOS commu- 
nicates at 115 Kbps, and Cyberflex at 56 Kbps. 
We analyze performance in detail in the follow- 
ing sections. 


5.2 Time line 


Figure 5 shows a time line of the kinit program. 


dtart Reset 
RPC Card 


O48. C—O” "3 


RKart Complete Start End Complete 
kinit RPC decryption decrypt kinit 
SS oe aie ore ee es Sr re Se ae 
(rime) 


Figure 5: Time line 

1) start kinit program, 2) start RPC to 
Kerberos KDC, 3) end RPC, do some 
host pre-processing, 4) initialize smart- 
card (reset, set baud rate, select key file), 
5) call decryption routine in smartcard, 6) 
store a ticket in a file, and do some post- 
processing. 


5.3 Breakdown 


Table 1 shows how much time is spent in each 
part of the protocol. Time is in seconds. 





part STARCOS | Cyberflex 
pre-processing (1,2,3) 0.307 
smartcard time (4,5) 2.617 
~— initialize card (4) 0.358 
— data transfer 0.100 
— decryption 1.047 
— misc 1.113 
post-processing (6) 0.037 
total 1.139 2.961 


Table 1: Authentication time breakdown 


Total time to authenticate with the STARCOS 
card is 1.139 sec. (2.961 sec. for CyberFlex 
Access). Smartcard-related tasks — initializa- 
tion, communication, and decryption — domi- 


nate, taking 83% (88%) of the total time. With 
an 8-bit data path and a 3.5 MHz clock, a 
smartcard is much slower than a workstation. 


The rest of time, including RPC communica- 
tion with KDC, is 0.197 sec. (0.344 sec.). Of 
the 0.944 sec. (2.617 sec.) of smartcard time, 
decryption takes 0.323 sec. (1.047 sec.), ini- 
tialization (card reset, set baud rate, select key 
file) takes 0.243 sec. (0.358 sec.), data transfer 
takes 0.053 (0.100) sec., and miscellaneous part 
takes 0.325 (1.113) sec. The miscellaneous part 
includes APDU handling overhead. 


As a non-programmable card, STARCOS 
shows better performance than Cyberflex Ac- 
cess, but not dramatically so. For STARCOS, 
we send APDUs that invoke the built-in DES- 
CBC method, while for Cyberflex, we coded 
and loaded a Java applet that receives a re- 
quest APDU and then calls a built-in DES- 
CBC routine. We think these two cases il- 
lustrate the tradeoff between performance and 
flexibility available to smartcard developers. 


6 Discussion 


6.1 Related Work 


Here we relate this effort to secure computer 
systems, secure bootstrapping, smartcard au- 
thentication, and smartcard integration with 
Kerberos. 


Secure computer system 


We refer to two efforts that share our goal of 
building a secure computer environment. 


In the Dyad system [22], Tygar and Yee build 
an operating system for a tamper-proof copro- 
cessor that has the ability to process and store 
secrets. The coprocessor provides secure boot- 
strapping, secure logging, and copy protection. 


The Dyad approach is top-down: unlike most 
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security protocols, Tygar and Yee do not as- 
sume security of components of computers such 
as operating systems because an adversary can 
reload the kernel. ‘To address this problem, 
they build special purpose hardware and an 
operating system for it. This approach differs 
markedly from ours. 


Another related, top-down approch is de- 
scribed by Lampson et. al. [14], who develop 
a theory of authentication for distributed sys- 
tems based on an access control model. They 
build tools necessary for secure systems, such 
as encrypted channels, boot strapping, nam- 
ing, and program loading. Accompanying the 
design of these tools are formal proofs of their 
security. Finally, they build an operating sys- 
tem to take advantage of the tools. 


Both Dyad and TAOS take top-down ap- 
proaches: they start with a well-developed the- 
oretical framework, then design secure hard- 
ware to support the theory, then build oper- 
ating systems based on them. 


Although these approaches are substantive and 
technically sound, they are not practical for 
most existing computer environment because 
they build new operating systems from scratch. 
We take a more pragmatic and experimental 
approach and build from the bottom-up for 
rapid implementation and deployment. We 
employ currently available, secure, inexpensive 
hardware in the form of commercial smart- 
cards, integrate them with prevalent standards, 
and fit them with minimal effort into our exist- 
ing computer environment. 


A disadvantage of our approach is that we still 
rely on the security of hardware and operating 
systems, of which we cannot be sure. (Often, 
we have great doubts!) For example, if an oper- 
ating system is completely replaced, it is quite 
possible for an adversary to use stolen creden- 
tials to access resources. 


Our solution to this problem is to store all crit- 
ical secrets in a smartcard. A smartcard is 
tamper-resistant hardware, so no matter what 
happens to the hardware and the operating sys- 
tem, we can be confident that the secrets in 
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the smartcard remain safe. In the previous ex- 
ample, even if the operating system is compro- 
mised, critical information in a smartcard, such 
as authentication keys, can not be accessed by 
the adversary. Therefore, our approach signifi- 
cantly “raises the bar” of security in a computer 
system with relatively small cost. 


Secure Bootstrap 


Arbaugh et. al. introduce AEGIS, a secure 
bootstrap process [1]. They add a small PROM 
to commodity hardware. The PROM is as- 
sumed to be secure, 2.e., it is not replaced by 
the adversary. The PROM contains execution 
code to start bootstrapping and to check dig- 
ital signatures. During the bootstrap process, 
all execution code is verified by a digital sig- 
nature. At the end of the bootstrap process, a 
commodity operating system, FreeBSD in their 
example, starts up. As the execution code in 
PROM and the bootstrap process are trusted, 
the operating system is trusted when it starts. 


AEGIS is similar to our approach in the sense 
that both try to minimize components that 
must be trusted: the added PROM in AEGIS, 
and the smartcard in our case. Also, both 
use commodity hardware and software. AEGIS 
and our approach complement one another be 
cause AEGIS aims at starting an operating sys- 
tem securely, and we aim at establishing a se- 
cure computer environment built on top of op- 
erating systems. 


Authentication with Smartcards 


Several authentication protocols that use 
smartcards have been proposed. For exam- 
ple, Rubin proposes one-time password ({18], 
Shoup and Rubin propose session key distribu- 
tion in the third-party setting [20], Leach pro- 
poses the use of zero knowledge authentication 
[15], and Wang and Chang propose use of pub- 
lic key authentication in smartcards [23]. Each 
of these concentrates on one-to-one authentica- 
tion, such as when a user logs in to a computer. 
This differs from our approach in that we in- 
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tegrate a smartcard into a standard authenti- 
cation protocol already in heavy use. Among 
them, only Shoup and Rubin’s protocol has ac- 
tually been implemented with a smartcard [10]. 


Smartcard Integration with Kerberos 


Looi ef. al. describe smartcard integration 
with SESAME, which is compatible with Ker- 
beros V5 [16]. Their approach is very similar to 
ours. They describe two ways of accomplishing 
smartcard integration: 


1. Store a user key in a smartcard, load the 
key into a workstation, and use it for de- 
crypting TGT instead of a derived key 
from a password. 


2. Decrypt TGT in a smartcard. 


Method 1 is not as secure as method 2 because 
the user key is loaded in a workstation. If the 
workstation is not trusted, the key is vulner- 
able. For example, a Trojan horse attack can 
easily obtain the key. Method 2, identical to 
our method, had not been implemented at the 
time of their writing. 


6.2. DES in Smartcards 


Many vendors claim that their smartcards sup- 
port DES, but we had a very hard time getting 
a smartcard that meets our requirements, even 
though all we need is pure, unadulterated DES. 
Here we list some of the DES-capable smart- 
cards that let us down when examined closely: 


e Schlumberger CryptoFlex 


Only custom-made cards have DES. 


e Schlumberger MultiFlex 


DES is available in the form of an in- 
ternal authentication command, which re- 
turns only six the eight bytes of output 
data. 


e IBM MFC 


The smartcard encrypts a_ ran- 
dom number challenge presented by 
SCT_CMD_AUTHENTICATE command, 
but does not document a general-purpose 
DES interface. 


MAOSCO MULTOS 


The card supplied with the _ devel- 
oper’s kit encrypts with a fixed key, 
0x41ad8223a90be2a1. According to the 
manual, “for security reasons,” DES uses 
a “known cryptographic key.” (!) 


General Information Systems OSCAR 


The DES key is XOR’ed with a random 
number before it is used. According to 
their e-mail: “The keys are XOR’ed with 
a random number for security reasons.” 
While this may help secure the serial link 
between the terminal and the reader, it 
makes the card useless for enterprise se- 
curity deployment. 


Gemplus GPK 


The key size is limited to 40 bit, a flaw not 
shared by Kerberos. 


Eventually we found smartcards that satisfy 
our needs: Giesecke & Devrient STARCOS and 
Schlumberger Cyberflex Access. 


7 Future Direction 


Comparison among several smart- 
cards 


We plan to implement the Kerberos authenti- 
cation protocol in more smartcards, e.g. IBM 
MFC, MULTOS, and so on.* We expect to find 
some differences in their performance because: 


e Some of the smartcards have DES CBC 
mode. 


4If we receive smartcards with DES. See our discus- 
sion in Section 6.2. 
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e Some of the smartcards have key schedul- 
ing APIs. 


e Communication speed differs among 
smartcards, 


Wealso expect to find differences in user friend- 
liness and stability among smartcards and de- 
veloper’s kits. 


Kerberos tickets in a smartcard 


As we argued in Section 2, it is desirable to 
store keys in a smartcard rather than in a work- 
station. Therefore, storing session keys in ad- 
dition to the user key in a smartcard adds se- 
curity to the protocol. If tickets are stored on 
a smartcard, it is secure to leave a worksta- 
tion to have a cup of coffee as long as the user 
brings the smartcard with her. Although an 
adversary can access the console, he cannot ac- 
cess resources protected by Kerberos because 
he does not have session keys. 


Smartcard integration with PAM and 
NT-PAM 


We will address secure single sign-on. Com- 
bined with PAM [19] or Windows NT-PAM [9], 
smartcards can provide secure single sign-on [7] 
because they can store keys and passwords se- 
curely, and can be integrated into existing au- 
thentication protocols, as we have shown in this 
paper. 


8 Conclusion 


In this paper, we identified certain limitation 
of Kerberos and ways that a smartcard can 
counter them. We suggested a protocol that 
takes advantage of the secure features of a 
smartcard to enhance security of Kerberos. 
The protocol is implemented with a Giesecke & 
Devrient STARCOS smartcard and Kerberos 
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V5-1.0.5. Performance evaluation shows the 
protocol runs reasonably fast. 
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Abstract 

The World Wide Web has become the de facto interface 
for consumer oriented electronic commerce. So far the 
interaction between consumers and merchants is mostly 
limited to providing information about products and 
credit card based payments for mail orders. This is 
largely due to the lack of security currently available for 
commercial transactions. At the moment the only 
security mechanism present in most browsers is the 
Secure Socket Layer (SSL) which is limited to 
authentication and encryption of the HTTP session. It 
does not aim to secure transactions. 

This report describes the design of a new three party 
authentication and key distribution protocol to serve as 
a foundation for WWW based transactions. Instead of 
having a radically new design it is derived from 
KryptoKnight protocol family developed at IBM. An 
important design consideration has been that it can be 
implemented with existing smart card technology. 
Specifically the Dutch Chipper and ChipKnip cards 
have been examined for their applicability. The result is 
an ABK(t) type protocol that runs with any card that 
supports either the ISO7816 internal authenticate 
command or the En726 read stamped or protected read 
instructions. 

Secondly a prototype has been implemented in Java 
that can run in either the Java Development Kit or the 
Netscape or HotJava browser. Though Java was not 
designed for implementing hardware drivers it has 
proven perfectly suitable for communication with smart 
cards. Also it has effectively demonstrated its cross 
platform capabilities over multiple operating systems: 
except for a small native library to talk to the RS232 
port the same code runs on Win32, Linux and the NCD 
network computer. 


1. Introduction 

The subject of this graduation assignment is to design 
and prototype a mutual authentication system for 
WAN-based Client/Server applications. Implementation 
of the system shall be based on common Intermet 
technology. More specifically the applications are 
assumed to be WWW enabled, with a Java capable 
WWW browser on the client side and an HTTP server 
on the server side. 

The system shall provide the basic elements for the 
initialization of a secure channel from client to server: 
authentication and (session) key negotiation. Properties 


of the channel it self, such as encryption, message 
integrity, and non-repudiation, etc., are beyond the 
scope of this assignment. 


Some countries, notably the USA and France pose 
restrictions on the export of strong encryption 
technology. In order to accommodate unrestricted 
development in these countries the authentication 
system shall be built only with cryptography that may 
be exported legally. 

Since the primary users of the system are consumers 
ease of use is very important. Consumer oriented 
systems for securing transactions that rely on soft keys 
instead of hardware tokens, such as the IPay system 
have proven to be difficult to use and administer. 
Hardware tokens on the other hand store the keys and 
the algorithms that may use them internally, safe from 
harm by careless users or hard disk crashes. Therefore 
this assignment will investigate the possibilities to use 
hardware tokens as security providers. Particularly 
smart cards will be examined because they are designed 
for this purpose. Moreover since the introduction of two 
nation wide electronic purse systems, the Chipper and 
the ChipKnip, by all Dutch consumer banks the 
majority of Dutch consumers owns one ore more smart 
cards. 

For reasons of cost and availability it is attractive to be 
able to reuse these existing smart cards to authenticate 
clients and servers to each other. Typically the server is 
not the card issuer or owner of part of the card and 
therefore has no knowledge of the keys used by the 
smart card of the client. One option would be to install 
a security module containing all relevant keys at each 
server. This approach is used for the aforementioned 
ChipKnip and Chipper electronic purse 
implementations. This was motivated largely by the 
restriction that the purse transactions could be 
performed off line, without intervention of a central 
system. However in case of transactions on the Internet 
offline processing is not required. When considering the 
security and management issues generated by massive 
deployment of security modules, using a_ central 
security server is a preferable alternative. Consequently 
the authentication protocol features three parties: a client 
(the consumer), a server (the service provider) and a 
trusted third party (the smart card issuer, e.g. a bank). 
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The core of the system is a new cryptographic protocol 
that can be implemented with smart cards. It shall 
provide: 

e Source authentication. The protocol should return 
an identifier of the peer party. This identifier may 
be persistent, such as an account or membership 
number or a transient, valid only for the duration of 
the session. In case of persistent IDs the trusted 
third party guarantees that the presented IDs belong 
to the communicating party. The protocol shall fail 
to complete if either party is not authenticated. 

e Key negotiation. If authentication is successful, the 
protocol shall retum a shared secret to both 
communicating parties. This secret can be used as 
a session key to provide message authentication, 
message integrity and optionally encryption. 


1.1. Elements 

Within an authentication system one can identify 

several elements. These include the users of the system 

of course, others are: 

e Identificators. These are the objects the users (both 
clients and servers) use to prove their identity. 
They contain an identifier for their owner and a 
mechanism to authenticate this identity. In this 
assignment the application of smart cards as 
identificators will be investigated. 

e A Trusted Third Party (TTP). The issuer of the 
identificators. It is trusted by both client and server 
parties, hence its name. 

e Semi Trusted Computing Base. The to be secured 
application runs in this environment. The semi 
trusted computing base is trusted not to 
compromise the security of a single session of the 
application, but not trusted enough to protect long 
term secrets used for identification. 


1.1.1. Requirements on the Identificators 
In physical life people prove their identity with an 
identification paper, for example a passport. In 
‘computer life’ we'll need a similar identificator. 


Passports and alike contain three parts: 

e An organization wide identifier: a social security 
number, a name, age, birthplace, birthday tuple, 
etc. This information is used within _ the 
‘organization’ to uniquely refer to a person. 

e Biometric identification information: photographs, 
age, height, eye color, etc. This data set should 
unique describe anyone bearing a passport and 
thereby link a passport to one unique individual. 

e Physical authentication proofs: watermarks, 
uncopiable prints, special paper, etc. They should 
prove the passport is genuine and actually issued 
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by the claimed authority (and thereby prove that 
this authority attests to the identity of the bearer). 


So passports rely on biometric verification and the 
unfeasibility to physically forge them. Biometric 
verification relies on the trusted verificator (e.g. a 
customs officer) to be present at the same place as the 
identificator (passport): the biometric properties are 
public, their security lies in their unforgeability. 

Since we are looking for a distributed protocol the peer 
party cannot know whether properties are actually 
measured or just pretended to be measured. 


Challenge Response [dentificators 

Instead of relying on publicly known properties that 
may be forged, the identifying properties should be kept 
secret. You prove your identity by showing you know a 
unique secret that no other user knows, without 
disclosing it. A common method for this is a 
challenge/response protocol: party A sends a random 
number (the challenge) to party B, whose identity has 
to be verified. B returns a response calculated from the 
challenge and its unique secret key. The calculation has 
the property that it is infeasible to determine the key 
from the challenge response pairs. Nor is it possible to 
deduce new pairs from known ones. Verification of the 
response is only possible for parties knowing the secret 
used in the calculation. They can reproduce the 
challenge/response calculation and verify the response 
given by the authenticating party. 


Physical, electrical and functional properties of smart 
cards are standardized in ISO standard 7816 ({ISO89], 
(ISO92] and [ISO93]). The majority of currently 
deployed cards implement 7816 parts 1 to 3 and most 
application level commands in part 4. The latter part 
includes some standardized commands to perform 
challenge/response calculations. The actual choice and 
implementation of a particular algorithm is left to the 
card manufacturer. 

Minimally we require the card to contain an identifier 
and a key that are unique for the owner of the card and 
maintained by the Trusted Third Party (TTP). 
Examples of the identifiers are (bank) account numbers, 
social security numbers, membership numbers, etc. 
Secondly we require the card to offer some challenge 
response mechanism using the unique key that can 
prove the validity of the ID supplied by the card. 


1.1.2. Requirements on the Trusted Third 
Party 

The Trusted Third Party is the organization issuing the 
smart cards or at least controlling the part of the card 
used for the protocol in case of Multi Function Cards 
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(MFCs). It has knowledge of the persistent keys used in 
the protocol. As the name suggests, the client and 
server trust the TTP to provide them accurate 
information. Also they trust the TTP to issue 
identificators that have sufficient security provisions to 
keep the persistent keys secret. 


1.1.3. Requirements on the Semi Trusted 
Computing Base 

A user may consider his or her computer and web 
browser to be a semi trusted computing base. People 
trust their computer and browser to communicate with 
the service provider, that is they trust it not to 
compromise the communication, for example to relay it 
to another party, to manipulate it, etc. 

However Internet enabled computers are compromised 
ona daily basis all over the world, so one cannot rule 
out the possibility a hacker gains control over the web 
browser or even the whole computer. An important 
feature of the authentication system has to be that in 
such a case compromise will be incidental and not 
total: once the security breach in the semi trusted base 
has been fixed compromise should no longer be 
possible. Note that this is different from a breach in the 
security of the trusted computing base: once a smart 
card has leaked its secret nothing can be done to restore 
the security of that card. 


1.2. Standardized Cryptographic Features 
for Smart Cards 

Both the ISO 7816 and En726 standards only include 
commands that use secret key cryptography. 
Consequently their authentication mechanisms require 
that both parties (the card and the application) know the 
authentication key. 

ISO 7816 specifies a single command by which a card 
can authenticate it self to the outside world: the internal 
authenticate command. This is a_ straightforward 
challenge/response mechanism with challenges and 
responses of typically eight bytes (this is not mandatory 
though). Commonly this command is implemented 
with DES encryption in Electronic CodeBook (ECB) 
mode. Conversely the external authenticate command 
allows the outside world to authenticate it self to the 
card. 

ISO 7816 also specifies mechanisms for providing data 
integrity and confidentiality, labeled Secure Messaging. 
These do not seem to be implemented widely though, 
so they will not be discussed here. 

Additionally the En726 standard offers methods for 
authentication and concealment of data on the card. 
Elementary files can be given access conditions, which 
specify whether and how the files may be read and/or 
updated. Among the conditions are “ALW” (for 


always), “NEV” (for never), “PRO” (for protected) and 
“ENC” (for enciphered). The “PRO” access condition 
mandates that a cryptogram shall be sent along with the 
data read from or written to the card. This cryptogram 
is the result of a keyed MAC over the data and a 
challenge. The “ENC” access condition is an extension 
of the “PRO” condition. It mandates that all data shall 
be enciphered as well as protected by a cryptogram. 


1.3. Key Management of Some Smart Card 
Systems 

Electronic purses like Chipper and ChipKnip are 
designed for off line use: the customer should be able to 
pay the merchant without the need for a connection to a 
central server of a bank. This means only two parties 
are involved: just the card of the customer and the 
Payment Terminal System (PTS). Generally the part of 
the terminal that provides the security (contains all 
keys, etc) called the Secure Application Module 
(SAM), is a smart card as well. 

Secret key based authentication requires both parties to 
share a common secret. The simplest method to arrange 
this is to have a single organization wide key stored in 
all smart cards. In closed systems deployed within a 
single organization, authentication with a single key is 
still commonly used. An example is the Closed 
Electronic Purse on the Studenten ChipKaart of 
1995/96 [Hoekstra97]. 

For larger systems such as a nation wide intersector 
electronic purse a single global authentication key is 
not a feasible solution: breaking the security of a single 
smart card, that is obtaining the key, compromises the 
security of the entire purse application. Failure of a 
single entity in the system results in failure of the 
security of the entire system. 

To remedy this electronic purses like Chipper and 
ChipKnip feature a unique authentication key per purse 
card. Obtaining the key of one purse card does not help 
you to forge other purse cards. After a couple of 
fraudulent purchases with a forged version of the cracked 
card the bank will notice the fraud (because more money 
was ‘downloaded’ from the card than was previously 
uploaded to it) and black list the card. The solution is 
only partial however: since every Payment Terminal 
System (PTS) should be able to authenticate every 
purse it should know all authentication keys. It is 
infeasible to store every key in a big database located in 
the PTS; we would be talking about something like 5 
million entries replicated in at least 50.000 databases. 
Instead the authentication key of a purse is determined 
by key transformation: the bank has a single master key 
that serves as a key encrypting key or key generating 
key over the ID number of the card: K purse = Exm(IDpurse) 
Or Kourse = MACkm(IDpurse). Now the SAM only needs 
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to know the master key from which it can deduce the 
purse key for every purse it has to authenticate. The 
purse itself contains only its own Kguse. Of course if this 
master key extracted from a SAM somehow, the entire 
system still is compromised completely. 


2. A New Protocol for Authentication & 
Key Distribution 

The KryptoKnight protocol family provides three party 
based authentication and key distribution built on 
exportable symmetric cryptography. It has most of the 
properties we desire. Nevertheless it has not specifically 
been designed for implementation with existing smart 
cards. For example it assumes party A and B know 
their respective keys Ka and Kg. For smart cards this is 
not true: neither smart card users nor applications are 
allowed to know the keys stored in the card. The 
operating system of the card only permits applications 
to initiate certain commands that use the key, but these 
are all executed within the secured environment of the 
card itself. 

This chapter describes the design of a three party 
authentication and key distribution protocol suitable for 
smart cards, based on the KryptoKnight protocol 
designs. More specifically the ABK variant of the 
KryptoKnight protocol will be adapted to a smart card 
compatible ABK(t) type protocol, named KLOMP 
(KryptoKnight-based Lightweight Open Mutual 
authentication Protocol). 


2.1. Assumptions and Constraints 

l. Only the server shall contact the trusted third party. 

2. Assumptions about the identificators used by the 
client and the server shall be minimized. 

3. The protocol shall be compatible 
contemporary smart card technology. 

4. The protocol shall be suitable for a Wide Area 
Network (WAN) environment. 

5. All cryptographic algorithms shall be legally 
exportable (out of the United State and other 
countries that put restrictions on export of 
cryptography). 

6. The protocol shall be stateless with respect to the 
trusted third party. 

7. The trusted party shall not need to give any 
response before successful authentication of both 
client and server. Specifically it shall not disclose 
any information about the client to the server before 
both client and server are authenticated and the 
client has given its consent. 


with 


Ad 1) In a typical Internet based client/server system 
the number of clients is much larger than the number of 
servers. Furthermore the relation between a trusted party 


and the application servers is more static than between 
the trusted party and the clients. Therefore both from a 
security and a topological viewpoint it is wise to limit 
access to the trusted party to the application servers. 


Ad 2) Minimizing the assumptions about identificators 
maximizes the reusability of the protocol. 


Ad 3) The protocol is specifically aimed at letting 
smart cards provide the security for it. It shall at least 
be implementable with ISO7816 or En726 compliant 
cards. 


Ad 4) The protocol is aimed at use in an Internet 
environment, which certainly is a Wide Area Network. 


Ad 5) Authentication and key distribution by them 
selves are exportable functions. In many cases they 
suffice and confidentiality by encryption is not needed 
for the subsequent transactions. With careful design it is 
possible to build a system that is both secure and does 
not rely on export restricted cryptography 


Ad 6) A stateless protocol considerably reduces the 

amount of administration to be kept by the trusted 

party. Keeping the server of the trusted party simple is 
important: 

e compared to the other parties, the authentication 
server has to handle many requests: whereas the 
client has to perform only one authentication, the 
application server has to perform as many 
authentications as there are clients connecting and 
the trusted third party has to serve requests fiom all 
the applications servers it serves. 

e asimple server is more robust than a complex one. 

e asimple server is more likely to be secure than a 
complex one. 


Ad 7) To ensure the privacy of users any information 
about them should be disclosed (to the application 
server) only after the user agrees to it, which means that 
both the user and the server should be authenticated 
first. Also for security it better not to have to send 
encrypted messages (tickets) to unauthenticated 
principals: it allows attackers to collect cipher texts 
which might help breaking the cryptographic protocols. 


2.2. Generating MACs with smart cards 

The KryptoKnight protocol needs to calculate 
authentication codes over messages longer than 32 
bytes. Smart cards may not support MAC generation 
over messages of that length. They often offer only 
limited support for generation of authentication codes 
over messages. Some methods are: 
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e 1SO7816 Internal Authenticate 

e En726 Read Stamped / Protected Read of freely 
writeable field 

e En726 Read Stamped / Protected Read of read only 
field 

e CBC-MAC based of one of the above methods. 


2.2.1. ISO7816 
command 

The ISO7816 Internal Authenticate command returns a 
keyed hash of a short message (the challenge) in order 
to authenticate the card to the outside world. This 
keyed hash can also be used to generate an 
authentication code over an arbitrary message. Since the 
challenge that the Internal Authenticate command 
accepts must have a limited length (typically 8 bytes), 
the message first has to be compressed using a secure 
hash algorithm. The compressed message is then fed to 
the Internal Authenticate command. In order to ensure 
freshness of the resulting Message Authentication Code, 
a random challenge number should be included in the 
message before compression. To put it in a formula: 
MACx(M) = InternAuth,(H(R // M)), where M is the 
message, K the authentication key and R a random 
number to ensure freshness. 

Although this method does yield a MAC generating 
algorithm, the compression of the message before the 
Internal Authenticate command does weaken it. For 
example in order to find two messages that collide 
(generate the same MAC) an attacker does not need to 
have access to the Internal Authenticate command. She 
only needs to find collisions in the secure hash 
algorithm. Any collisions found will then occur with 
any smart card regardless of the key. 


Internal Authenticate 


2.2.2. EKn726 Read Stamped 
Writeable Field 

The smart card supports the En726 Read Stamped or 
Protected Read methods and has a freely writeable file 
that can be read with (one of) these methods. This offers 
the best way to perform MAC calculation on the card: 
first write the message on the card and then read it back 
with the Read Stamped or Protected Read method. The 
only limitation is that the message has to fit into the 
file. 


of Freely 


2.2.3. En726 Read Stamped of Read Only 
Field 

In this case the smart card supports the Read Stamped 
or Protected Read methods but none of the files on the 
card is freely writeable. This gives the same 
opportunities as the /nternal Authenticate command: an 
8-byte challenge that yields an 8-byte response. The 
only difference is that the contents of the file have to be 
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sent to the verificator along with the response or else 
the verificator will not be able to reproduce the MAC 
calculation. 


2.2.4. CBC-MAC 

All of the above methods use an authentication code 
generating command only once. Depending on the 
speed of the card and the time constraints on the 
protocol this may be the maximum as well. But if one 
is permitted multiple invocations, either of the methods 
mentioned above can be used to build a CBC MAC, 
analogous to the ANSI X9.9 keyed MAC algorithm. 
The Read Stamped over Writeable Field and the CBC- 
MAC method generate MACs over the entire message, 
the others only over a compressed representation of the 
message, which is less secure, so the first are preferred. 
But since they might not always be available or feasible 
the protocol will be designed to work with the other 
two methods as well. 


2.3. Challenges, responses and authentica- 
tion proofs 

From the previous paragraph follows that minimally 
available is a challenge/response mechanism _ that 
accepts fixed length short challenges (of 8 bytes in most 
cases) and retums responses of the same length. In other 
words where KryptoKnight calculates MACs with Ka 
or Kg on complete messages, the new protocol first has 
to compress these messages. With a secure hash 
function the message can be mapped to a fixed length 
challenge that appears pseudo random. For example let 
Ca = H(Na, Np, B) and Cg = H(Na, Na, A). 

However this introduces a possible weakness: the space 
of possible challenges is much smaller. When the space 
is small enough it might be feasible for an attacker that 
has already has collected correct challenge/response 
pairs to try to find a Na (or Np) that yields a known 
challenge by brute force. For example if the challenge is 
64 bits big and the attacker has collected 2'° 
challenge/response pairs, every one in 2" nonces yields 
a challenge for which the response is known. With the 
currently available computing resources this is feasible 
by ‘brute force’. This attack is possible because the 
search fora suitable nonce can be performed off line. In 
order to limit this off line search the protocol may 
impose a time window outside of which the challenge 
is not valid. A window that is small enough renders a 
brute force attack infeasible: once a suitable challenge 
has been found the transaction has already expired. The 
challenges become: 

Ca = H(Na, Ns, T, B) and Cs = H(Na, Na, T, A), 
where T is a time stamp. 


2.4. Order and Direction of the Data Flow 
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The order in which the three parties communicate is 
largely dictated by the constraints put on the protocol: 
the limitation that the protocol should be stateless with 
respect to the TTP (constraint 6) implies that it shall 
be contacted only once during a protocol run. The 
contactor shall be the server (see constraint 1). So the 
protocol flow includes B> KB. 

Since A has to be notified about success or failure of the 
protocol B subsequently sends a message to A. And 
since the ID of A has to be known before contacting the 
protocol flow has to be at leat ADBOKDOBOA. 
From constraint 7 follows that both the client and 
server shall generate their authentication proofs before 
contacting the TTP. This in turn implies that the 
challenges the client and server identificator have to 
respond to cannot include a nonce from the TTP. 
Instead it has to be substituted by a time stamp. In 
order to establish challenges that contain nonces of both 
A and B and the time stamp, the protocol flow has to 
start with a message from B to A that contains B’s ID 
and its nonce Ns. If the protocol will be initiated by A 
it has to send a (possibly empty) ‘trigger’ message to 
B before that. This results in the following protocol 
flow: ADB9ADBIKDBOA. 


All in all the desired protocol can be called an ABK(t) 
protocol, using the naming convention of the 
KryptoKnight documentation. (The t after the K for the 
KDC = TTP, indicates the substitution of a timestamp 
for a nonce from the TTP.) Unfortunately the 
KryptoKnight family does not include a protocol of this 
type, so a new one has to be developed. 


2.5. Session Key Distribution 

The method of key distribution is also influenced by 
the constraints on the protocol. The KryptoKnight 
protocols all let the TTP generate the session key and 
distribute it with tickets to both the client (A) and 
server (B). As discussed before this has the drawback 
that an attacker may collect any number of tickets for an 
attack on the encryption algorithm without any 
authentication. 

In the new algorithm a different distribution mechanism 
is proposed: party A generates the session key, 
transports it encrypted (via party B) to the TTP, which 
decrypts the key and finally sends it to party B 
reencrypted with a key known to B. So in this case the 
session key is transported (from A to B) rather than 
distributed (from the TTP to A and B). 

A and B generate cryptographic proofs before contacting 
the trusted third party. In the same effort the session key 
can be generated as well: party A generates session key 
Kas with the same parameters as proof Pax it sends to 
the TTP. Since these parameters are either publicly sent 
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to the TTP or known by the TTP (in case of the key 
transforming key Ka), the TTP can reproduce the 
session key without further knowledge. 


2.6. Protocol Description 
The considerations in the previous paragraphs lead to 
the protocol flows depicted in figure 1. 


Step 1 might seem strange since it does not include any 
protocol data. Its purpose is to trigger the start of the 
authentication protocol and need not be explicitly 
performed: the protocol might be triggered implicitly 
when the client requests a secured action within the 
application protocol. 


In step 2 the server replies with an identifier for itself 
(B), a nonce (Ng) and a time stamp (T). T substitutes 
for a nonce Nx of the TTP because the TTP may 
contacted only once, after the challenge/responses have 
been performed at the client and server. The time stamp 
does not need to be very precise: it sets but a time 
window in which the authentication session has to be 
performed. It is checked by the TTP, so the clocks of 
the server and the TTP must have a time skew less 
than the allowed time window. A time window in the 
order of 5 to 10 minutes seems reasonable: it is small 
enough not to compromise the security of the protocol 
and wide enough to avoid the difficulties of tightly 
synchronized the two clocks. 


Steps 3 and 4 are split up in three parts: In step 3a the 
client calculates a challenge Ca to send to the 
identificator. This challenge should be a secure hash of 
Na, Np, T and B, where Na is a nonce generated by the 
client. Proposed is Ca = MAC; (Na // Ng // B). 

In step 3b the client collects the data from the 
identificator: the ID of the client (A), the type of the 
identificator (I,), the response on the challenge (Ka.), 
and optionally any extra data used in the calculation of 
the response (Da). Rather than having the TTP generate 
and distribute the session key, response Ka, will be 
used as a temporary key for the generation of session 
key Kap. The choice for key generating function /() 
depends on whether party B is allowed to leam 
challenge/response pairs of A’s smart card. In that case 
S@)=x will suffice else an (optionally salted) hash 
function has to be used. The authentication proof Pax is 
calculated from A, Na, Np and Kag using formula Pax 
= MACas(Na // Ng // A). Using Kas instead of Ka, 
makes the proof from A for the TTP identical to the 
proof from A for B: Pax = Pax 

In step 3c the client sends all parameters (A, Na, Ia, Da, 
Pax, B, Ng, T) to party B. 
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The server (party B) similarly generates a challenge 
(Cp) and retrieves the corresponding response (Ks.) from 
its smart card. However the server does not need to 
generate a session key nor should its authentication 
proof be verifiable by the client. Therefore it can directly 
apply response Kg, in its calculation of Pax. Since the 
server does not know Kag yet it cannot verify Pap. 
Instead the server sends all parameters (A, Na, Is, Da, 
Pax, B, Na, Is, Ds, Pax, T) to the trusted third party. 


In step 5 the TTP verifies all parameters received from 

B: 

is time stamp T valid? 

is A a valid and active client ID? 

is B a valid and active server ID? 

corresponds proof value Pax to the value yielded 

with genuine key of the client Ka? 

e corresponds proof value Ppx to the value yielded 
with genuine key of the client Ks? 


In case the authentication request passed verification, 
the TTP calculates the session key and encrypts it for 
the server using key encrypting function g(): Tapa = 


2(Ko., Kas, ....). if A may learn Kg, the function may 
be very simple again: g(x, y, ..) =x ® y. The TTP 
sends back the result, the ticket Ts,, to the server B. 


In step 6 the server decrypts the session key Kas. Now 
B is able to verify proof Pax, because Pax is calculated 
from secret Kap and the public values Na, Ns and A. If 
the verification either client A or the trusted third party 
are imposters or the communication has been tampered 
with. If verification is successful B generates proof Ppa 
forclient A and sends it to A. Finally A verifies proof 
Paa. 


2.7. Improvements on the protocol 

The basic KLOMP protocol has been designed to be 
implementable with any challenge/response capable 
identificator. With some identificators the protocol can 
be enhanced for better security. At the cost of some 
extra calculations also some potential weak spots can be 
eliminated. 


2.7.1. Collection of challenge / response 
pairs 


Smart Card Client Smart Card Server Trusted 
for Client for Server Third Party 
I A . I, e a 

1. request authentication | —-——4 | 
2. start of protocol! ! | | B, Np, T | 
3a. calculate challenge of client | Ci. | | | | 
card . | | | 
| Kee Diet t | \ 

3b. receive response LAs To Kaw “>i 
3c.calculate session key and | | AN Ts DyiPays BNE | i 
proof of authentication | r | | 

| | 

4arepeat Step 3a for server | | i: Cp , : 
4b.repeat step 3b for server | | | B, Ip, Kgw Dp | | 
: : —_—_—_——_—_—_—__—_—_ > , 

pf TB Ree a 

4c.repeat step 3c for server B, B’ B?_~B? Paw 
| | | —_—— ted 

5.verify repsonses, calculate | | | le BA | 
ticket for server and retum it | | | | | 
} ; j j Pad | 

6.confirm to client | le {—___=" i 


Figure 1: Data flow of the KLOMP protocol 


Ca = H(Na, Ns, T, B) 
Ka, = MACa(Ca, Da) 
Kas =f(Ka., ee) 


Pax = Pap = MACas(Na // Np // A) 


TBa = 2(Ko,, Kas, ie) 


Cz = H(Na, Na, T, A) 
Ka, = MAC3(Cg, Ds) 


Pax = MAC3.( Na // Np // B) 
Ppa = MACas(Na // Na) 
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The current protocol allows servers to collect 
challenge/response pairs of the identificator of the client. 
Conversely clients can collect pairs of the identificator 
of the server if they eavesdrop on the connection 
between the server and the trusted third party. The 
reason for this weakness is obviously the simplicity of 
the key encrypting and key generating function applied 
in the protocol. To remedy this let: 

Kap = H(Ka. // Na) and Tea = H(Ka. // Ns) ® Kap 


2.7.2. Clients searching for suitable C,’s 
Ifa rogue client knows some challenge/response pairs of 
the client identificator it may try to find a challenge he 
knows by trying different client nonces (Na’s). Of 
course the search must be completed before the time 
stamp T expires. In any case this attack can be 
prevented if the client already has to commit to a 
specific Na in step 1. A way to accomplish this is to let 
the client send a concealed commitment to the server in 
step 1: it has to send a verification parameter Va=H(Na, 
Sa). Here Sa denotes the salt used to randomize the 
hash, analogous to the salt in encrypted UNIX 
passwords. The salt is a public value, meaning that the 
client sends it together with V, to the server. The 
inclusion of the salt in the hash increases the input 
address space of the hash beyond the point where the 
server can deduce Na through a dictionary attack. So the 
secure hash and the salt prevent the server to deduce the 
challenge of the client before committing to the value of 
its own nonce Ng. Yet in step 3c the server can verify 
that the client already has chosen its nonce before it 
knew the server nonce, thereby eliminating the search 
for a suitable nonce. 


2.7.3. Time Window of Session Key Com- 
promise 

The session key Kap may be used not only to protect 
the integrity and origin of transactions between A and B 
but also to encrypt their communication. If the 
information exchanged between A and B has to stay 
confidential even after the session has ended, Kags must 
remain secret as well. Since Kag is calculated solely 
from long term key Ka and data susceptible to 
eavesdropping, compromise of Ka, will enable an 
attacker to recalculate all session keys, no matter how 
long ago the corresponding sessions took _ place 
(provided that he recorded those sessions of course). 
The same applies to the compromise of Kg, since it 
forms the basis for the transport key for Kags. In case of 
key distribution protocols implemented completely in 
software, like KryptoKnight, the best we can hope for is 
that K,nor Kg are ever revealed to other parties: there is 
no solution for this problem. 


However with hardware security tokens like smart cards 
the situation may be much better. Compromise can be 
divided in two levels now: 


1. An attacker obtains access to the smart card and 
particularly to the challenge/response generating 
command: this means that the attacker can obtain 
responses over arbitrary challenges. 

2. An attacker discovers the key (Ka or Kg) used by 
the challenge/response algorithm on the card. 


The second level equals the compromise of the key in 
an implementation in software only: the attacker can 
recover any session key. Luckily level 2 compromises 
are very unlikely to occur: smart cards are specifically 
designed to withstand any attempt (both logically and 
physically) to illegitimately retrieve the keys they 
contain. 

Level 1 compromises are far more likely to happen, in 
fact any stolen or lost card may be abused for it. 
Luckily these compromises are also less severe. The 
key authentication and distribution protocol does not 
take advantage of the different properties of level 1 and 
level 2 compromises: in both cases all session keys can 
be recovered. 

Depending on the implementation of the 
challenge/response mechanism on the smart cards, the 
vulnerability of old session keys may be eliminated for 
level 1 attacks. The challenge/response mechanism has 
to be based on a reversible function, such as DES rather 
than on a keyed one way function. The ANSI X9.9 
MAC generation algorithm used in the IBM Multi 
Function Chipcards is an example. It essentially is 
DES run in CBC mode. 

This algorithm has an ‘inverse’, that calculates a 
challenge from a message, a key and the corresponding 
Message authentication Code. In other words: let M be 
a message, K be a key, C be a challenge and R be the 
MAC of M under key K and challenge C (so R = 
MACx(C, M) ) then C = MAC”, (M, R). With an 
inverse MAC one can take advantage of the fact that the 


Xi Xx 





MAC 


Figure 2: ANSI X9.9 MAC algorithm 
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TTP has full access to the keys in the identificators, but 
users of the identificators do not: a user can encrypt a 
short message by simply having the identificator 
perform a MAC calculation with the message used as 
challenge. The TTP decrypts the message by applying 
the inverse MAC. The holder of the identificator 
cannot, because the identificator restricts the application 
of the key it holds to the forward MAC calculation. 

To strengthen the authentication protocol with 
reversible MAC’s the following formulas have to be 
used for the notarization keys Ka, and Ka.,: 

Kas = MACa(Ca, Da) + MAC's (Na, Da) = MACa(Ca, 
Da) ® Ra 

Kss = MACa(Cs, Ds) + MAC's (Na, Ds) = MACa(Cs, 
Ds)® Rp 

where Na = MACa(Ra, Da) and Ns = MAC3(Rs, Da) 
Now the notarization keys are offset with the randomly 
chosen values Ra and Rg respectively. The TTP can 
decode these random values because they are encoded in 
the nonces Na and Ng with a MAC calculation. Since a 
smart card does not offer a method to derive Ra or Ra 
from Na and Ng an attacker cannot calculate the 
notarization keys and consequently the session key. 


MAC 





Figure 3: 'inverse' of X9.9 MAC 


The TTP, on the other may derive the random values 
by applying the inverse MAC algorithm. 


3. Prototype Implementation 

In order to test the applicability and usability of the 
authentication protocol in actual WWW _ browser 
environments a prototype implementation has been 
built. Minimal goals for the implementation were Java 
1.1 compatibility with support for at least one RS232 
connected smart card reader and a commonly available 
smart card. For the latter, the ZeelandKaart and the 
Chipper, both incarmations of the IBM Multi Function 
Card were chosen. 

The prototype implementation has been split into two 
parts: an implementation of the authentication and key 
transportation protocol and an implementation of a 
smart card access library. The intention was to be able 


to plug in specific identificators in the authentication 
protocol, including ones not based on smart cards. 
Flexibility was an important design consideration. 
Adding support for new smart card interfaces or smart 
cards has to be easy. Also extending the protocol for 
extra security or ‘new features must not break 
compatibility. 


3.1. Smart Card Interfacing 

At the start of this project no Java API for accessing 

smart cards was available so one was developed as part 

of the project. The Smart Card API is layered 

analogous to the ISO 7816 standards: 

e Hardware layer: provides uniform access to different 
smart card interface devices. 

e Datalink layer: implements the T=0, T=1, etc 
datalink protocols described in ISO 7816-3 

e Transport layer: provides multiple concurrent smart 
card communication channels for datalink layers 
that support it (T=1). 


e Application layer: implements the application 
commands standardized in ISO 7816-4 and 
prEN726-3 


In order to maximize portability the bridge between 
native code and Java was put in the hardware layer. 
This meant the development of a native RS232 port 
access library that can be linked by the Java Runtime 
through the Java Native Interface (JNI). This library has 
been implemented for the Win32 and Linux platform 
with the JDK 1.0, JDK 1.1 and Netscape 3 & 4 Java 
Runtime Environments. Support for the NCD Explora 
network computer was added in pure Java. 

On top of the RS232 layer drivers have been built for 
the Towitoko ChipDrive (see [Towitoko97]) and the 
DumbMouse smart card interface [BillSF96]. 

For the complete API and JavaDoc documentation, see 
[Bakker98]. 


3.2. Smart Card based Identificators 

As part of this investigation several smart cards have 
been examined for their applicability as identificators in 
the authentication protocol: the Studenten Chip Kaart 
(SCK) 1995/96, the Zeeland Kaart, the ChipKnip, the 
Postbank Chipper and the Studenten Chip Kaart 
1997/98 supplied to students at the Technical 
University of Delft. 

Except for the ChipKnip, which is a Bull CP8 Transac 
CC 60 payment card, all cards are based on the IBM 
Multi Function Card OS that implements (a subset of) 
the ETSI En726 smart card application layer. (All cards 
offer an ISO7816-4 command set, the ChipKnip over 
datalink layer T=0 and the others over T=1). 
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The ChipKnip turned out not to be compatible with 
KLOMP since it provides authentication only within 
the proof of debit step of a payment transaction, not 
separately [BeaNet96]. The other cards provide either a 
‘protected read” or En726 ‘read stamped’ method, 
which both include ANSI X9.9 MACs. With these 
methods improved KLOMP can be implemented. 
Experiments proved the MAC implementation on the 
Zeeland Kaart to be insecure however. 


3.3. Password based Identificators 

For testing purposes also a_ password based 
challenge/response identificator has been built. It can be 
considered a software emulation of a smart card that 
implements the JISO7816 _ internal authenticate 
command. The password-based identificator simply 
asks the user for a user ID and password to perform 
MAC calculations with. In this case the cryptographic 
functions are processed in the semi trusted computing 
base instead of in a trusted computing base. Of course 
the consequence is that compromise of the semi trusted 
computing base fully voids the security of the 
identificator. 


3.4. Protocol Implementation 

A prototype of KLOMP using password-based 
identificators has been written for the Java 1.1 platform. 
Using smart card based identificators was not possible, 
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Figure 4: Class Diagram of the Protocol 
Implementation 


USENIX Workshop on Smartcard Technology (Smartcard '99) 


because no smart cards were available of which the keys 
were known. Figure 4 shows a global class diagram of 
the prototype. At the TTP the identificator factory 
builds identificators by looking up users and passwords 
in a PostgreSQL connected through JDBC. The 
ClientAuthenticator, the ServerAuthenticator and 
TrustedThirdParty communicate through Java Remote 
Method Invocation (RMI). Java 1.1 includes a class for 
generation of MDS message digests, so this algorithm 
has been applied for all secure hashes. The prototype is 
available at [Bakker98-2]. 


3.5. Running the Prototype 

Since the prototype protocol implementation is written 
in pure Java, so it should run with any Java 1.1 
compliant runtime. (The prototype does connect to a 
pure Java UserdID/Password identificator by default, 
therefore it does not need a native RS232 access 
library). The server also needs the Java Generic Library 
(version 3.0) and the TrustedThirdParty needs a JDBC 
driver, in this case one for PostgreSQL. A PostgreSQL 
database containing the user table has to be accessible 
for the TTP. 

A small client has been written that repeatedly initiates 
the authentication protocol and times the duration for 
completion. The measurements of a typical run of this 
applet are shown below: 





Here the applet was running the protocol on a Pentium 
II 233 with Red Hat Linux 4.0 and JDK 1.1.1v2 
generated the above log. The first run of the protocol 
takes clearly much longer than the other ones. This is 
due to the initialization of the RMI channels between 
the parties: it causes loading of many Java RMI classes 
into the runtime. Also the Java serialization mechanism 
has to perform elaborate hash calculations for every class 
serialized. These timings should not be considered an 
indication of the speed of the protocol in a typical 
application environment: the JDK 1.1.1 for Linux is 
much slower than the average Java implementation, for 
example it does not contain a Just In Time (JIT) 
compiler. The above test runs were performed with all 
three processes (client, server and TTP process) and the 
PostgreSQL database on the same machine. Several 
other test runs have been performed with these parts 
running on separate machines running different 
operating systems. Besides Linux the system was 
tested on Sparc Solaris 2.5.1 and WindowsNT 4.0. 
Other than speed no functional differences were observed 
with the different configurations. Also the PostgreSQL 
JDBC driver did not have any problems in accessing 
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the database remotely. All in all the binary code 
portability of the Java prototype implementation scored 
100%. 


3.6. Application of the Smart Card API 
Separately from the protocol prototype, the smart card 
access code has been applied in a project for the 
Landelijk Instituut voor Sociale Verzekeringen (LISV). 
In this demonstration system people can register and 
login to the HTTP based application by entering their 
Chipper or ChipKnip card. A Java applet reads the 
account number and a password from the card and sends 
it to the web server for simple password based 
authentication. The applet takes less than half a second 
to read the card and send the logon _ request. 
Furthermore the applet couples to (Netscape) 
JavaScript. At the registration page a Javascript routine 
uses this coupling to read name and address information 
from the Chipper card and fill the registration request 
form with it. 


4. Conclusions 

The ISO7816 standards for smart cards provide basic 
functionality for authentication through the internal 
authenticate command. Together with the storage of an 
ID this command allows us to build challenge/response 
identificators. It has been demonstrated that with such 
identificators it’s possible to build an intrinsically 
secure three party authentication protocol (called 
KLOMP). Furthermore KLOMP_ imposes few 
requirements on the trusted party, eg. no 
administration of sessions is needed for the 
authentication, no information has to be returned before 
both client and server have been authenticated. Also 
KLOMP separates authentication from privacy through 
strong encryption, so the system does not suffer from 
cryptography export regulations like those imposed by 
the US. The incorporation of encryption of short 
messages with ‘inverse’? MAC’s strongly enhances the 
security of the protocol to a point where session keys 
are still secure even the smart card is stolen or other 
wise abused. This gives hardware-based identificators 
like smart cards a definite advantage over mechanisms 
that rely solely on software. 

Currently the majority smart cards used in Holland are 
either a version of the IBM Multi Function Card (the 
“Chipper”) or a ChipKnip. This is mainly a 
consequence of the massive scale at which the joined 
banks and the PostBank introduced the ChipKnip and 
the Chipper to the public. Though both are ISO7816 
compliant cards, neither base their security on the 
internal authenticate command (even though the MFC 
at least implements it). The MFC does provide two 
other challenge/response based commands that can be 


used as a substitution. The MFC therefore is 
compatible with the proposed authentication protocol. 
Unfortunately the ChipKnip cannot be adapted to the 
protocol because it lacks a transactionless authentication 
method. 

The authentication protocol has been successfully 
implemented in Java. It has been tested on the Linux, 
Solaris and Windows32 platforms, demonstrating the 
cross. platform capabilities of Java. The time 
measurements performed with the relatively slow Linux 
JDK 1.1.1 indicate that the protocol does not require an 
unacceptably long time to complete. 
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conventions 


X concatenated with Y 

X exclusive ORed with Y 

Party X’s master secret (= a long term 
key shared with the TTP) 

Party X’s key transforming key (= a 
derived key shared with the TTP for the 
duration of a session) 

Secret session key shared by X and Y 
Encryption of M under key Kx 
Decryption of M under key Kx 


a secure hash of Mj, ..., My 

Message Authentication Code for 
message M under key Kx 

Message Authentication Code for 


message M under key Kx with challenge 
C. The algorithm by which the 
challenge is inserted in the MAC is 
either unknown or undetermined. 

Inverse MAC for message M under key 
Kx with response R: 

MACx(C,M) = R < MAC? (R,M) = 
Cc 

anonce generated by X 

a challenge for Ix 

The identificator owned by X 

Data used by Ix to calculate MACs 

a MAC calculated by Ix based upon 
challenge Cx 

Proof of authentication by X_ for 
verification at Y 

a ticket for X containing the encrypted 
session key Kxy 

The client 

The server 

The Key Distribution Center (= the 
Trusted Third Party) 


a timestamp 
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ABK(t) 


CA 
CBC 
CHV 
ECB 
DES 
DSS 
ETSI 


HTTP 
ICC 
ICV 
IEP 
JDK 
JVM 
JNI 
KDC 
KEK 
KET 
KGK 
KTK 
MDS 
MFC 
NC 
PIN 
PTS 
RMI 
SAM 
SCM 
SHA 
SSL 
TBP 


Three party authentication protocol in 
which a time stamp is used to substitute a 
nonce for party K. 

Certificate Authority 

Cipher Block Chaining (mode) 
Card Holder Verification (number) 
Electronic Code Book (mode) 
Data Encryption Standard 

Digital Signature Standard 
European Telecommunication Standards 
Institute 

Hyper Text Transfer Protocol 
Integrated Circuit Card 

Initial Chaining Vector 

Intersector Electronic Purse 

Java Development Kit 

Java Virtual Machine 

Java Native Interface 

Key Distribution Center 

Key Encrypting Key 

Key Expiration Time 

Key Generating Key 

Key Transforming Key 

Message Digest number 5 

Multi Function (Chip)Card 
Network Computer 

Personal Identification Number 
Payment Terminal System 
Remote Method Invocation 
Secure Application Module 
Secure Cryptographic Module 
Secure Hash Algorithm 

Secure Sockets Layer 

Trusted Third Party 
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Abstract customer and the software publisher more convenient. 


This paper shows how these new technologies add a 
This paper describes public-key protocols for binding great degree of flexibility and ease of use to software 
software licenses to tamper-resistant smart cards, for license management and hardware-based copy protec- 
transferring licenses between cards, and for purchasing __ tion. It is possible to use the new technique in combina- 


them on-line. The protocols support software distribu- _ tion both with conventional software sales through retail 
tion both through retail stores and over the Internet. The Stores and with Internet commerce. The protocols pro- 
user can transfer licenses from several cards onto a sin- posed in this paper require public-key cryptography on 
gle card to avoid juggling between several cards in the the smart cards but otherwise they are extremely sim- 
reader. The protocols are based on signed delegation cer- ple. The license information is in the form of signed cer- 
tificates that are mostly stored outside the smartcard. A __ tificates and can be managed mostly outside the smart 
smart card reader and cards capable of public-key signa- cards. 

tures are the only new hardware needed. The protocols 

are easy for the user and simple to implement and ana- The main threats that we address are multiple instal- 
lyze. We prove the security of the transfer protocol. lations of software from a single-license distribution 


medium and production of counterfeit copies by profes- 

sional pirates. These types of copying appear to have the 

greatest impact on the software publishers’ revenues. 
P sntroducuon Another recent development, robust copyright-marking 
techniques such as watermarking [9], helps in resolving 
legal disputes over the ownership of data. However, it 
does not prevent copying of programs because the owner 
and copyright status are normally obvious from software 
products. A level of access control is needed to help 
the users make the right choice. It should be easier to 
buy than to copy. Also, copy-resistant physical tokens 
are needed to slow down the professional pirates whose 
aim is to mass-produce copies and market those as orig- 
inals. We recognize that there are always ways to work 
around the protection mechanisms. What can be done is 
to increase the time to market for pirated copies and to 
ensure that pirated products cannot be sold as authentic 
to unsuspecting customers. If honest and security con- 
scious users are alarmed about tampered products, they 
are likely to buy authentic ones instead. 


Unlicensed use of computer software has always been 
a major concern for the software industry. Lately, the 
piracy problem has been highlighted by the introduction 
of the Internet as a distribution channel [11], and the rise 
of content industry whose products are often collectively 
labeled as multimedia. 


Most copy-protection and license management tech- 
niques have either proven ineffective or too restrictive 
for users to accept them. Thus, a majority of mass- 
market software products today are sold without any 
technological protection, which leaves marketing and le- 
gal battles as the only means for the software industry 
to defend itself. However, current advances in technol- 
ogy are opening new possibilities whose impact on li- 
cense management should be assessed. First, with the 
popularity of smart cards, intelligent hardware tokens 
are becoming much more affordable. Second, computer 
networking makes two-way communication between the 


The rest of the paper is organized as follows. We be- 
gin with a short introduction to copy protection with 
tamper-resistant modules in Sec. 2. Sec. 3 gives an 
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overview of license transfer and Sec. 4 the protocol 
details. Sec. S continues with a protocol for on-line 
purchase of licenses. Techniques for strengthening the 
copy-protection are discussed in Sec. 6 and prevention 
of license theft in Sec. 7. Finally, we summarize the 
assumptions and advantages of the suggested protocols 
in Sec. 8 and list some possible extensions in Sec. 9. 
Sec. 10 concludes the paper. The Appendix contains a 
proof that the protocols cannot be subverted to copy li- 
censes. 


2 Copy protection with smart cards 


The only theoretically secure copy-protection arrange- 
ment is to deliver the code in encrypted form and to de- 
crypt and execute it inside a tamper-resistant processor 
[14, 15, 6]. In practice, such processors cannot be man- 
dated and the code is exposed to insecure user equip- 
ment. Therefore, copy-protection is always to some ex- 
tent security by obscurity. 


In practical protection mechanisms based on a hardware 
token, a user license is embodied by a copy-resistant 
piece of hardware. The software or the operating sys- 
tem checks for the presence of the token and refuses to 
run without it. 


A common type of token is a dongle that is inserted in 
a communications port on the workstation that is to run 
the software. If smart card readers become more com- 
mon, a smart card is the obvious choice for a token. This 
is because the production cost of a single smart card is 
negligible compared to the cost of a software license. 
It would not be impossible to routinely distribute smart 
cards with all shrink-wrap software. 


Robust mechanisms for checking the authenticity of the 
hardware token are based on a cryptographic key that is 
never stored or used outside the tamper-resistant token. 
The security of the mechanisms depends on two assump- 
tions of technical intractability: it must be too expensive 
or time-consuming to reverse engineer the smart card in 
order to obtain the hidden secrets in it, and it must be 
equally difficult to modify the software to run without 
the card. Both of the assumptions present difficult prob- 


lems of their own. This paper leaves them for others to 


solve. Tamper-resistant smart card technology is an ac- 
tive area of research [1, 8, 10], as is authenticated boot- 
ing of software. 


Unfortunately, dongles or smart cards are unpopular 
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with users. The main objection has been that the protec- 
tion mechanisms for different software packages often 
interfere with each other. Even if the protection mecha- 
nism for each individual product is well designed, they 
might become unusable together. This is a major prob- 
lem for smart cards since a single card must not be al- 
lowed to monopolize the card reader. In order to prove 
presence of a token for different software packages, one 
may have to repeatedly insert different cards into the 
reader, an annoying practice sometimes referred to as 
smart card juggling. 


We will describe a solution for binding software licenses 
to smart cards and for transferring them from card to 
card in such a way that the juggling is eliminated. 


3 License transfer with delegation certifi- 
cates 


In order to achieve flexibility and ease of use, our goal is 
to allow a single smartcard to act as a token for arbitrar- 
ily many software packages. The licenses are distributed 
on cards that the customers get bundled with each soft- 
ware package. Normally each card holds only a single li- 
cense. With a simple procedure, the licenses on one card 
can be transferred onto another card. After the transfer, 
the “empty” card may be discarded. 


Every card has a unique public-private key pair. The 
private key is stored on the card and never revealed to 
the outside. At any time when the card is in the reader, 
it will respond to a challenge to prove that it, indeed, 
has the private key corresponding to the public key. This 
way, the software can check that the card associated with 
the license is present in the reader. 


It is still necessary to bind a license to the public key. A 
convenient way to do this is to issue a certificate to the 
public key of the card. The certificate will be signed by 
the software publisher’s master key and it will be verified 
with a public key incorporated in the software or in the 
operating system. The certificate can be stored outside 
the card. In fact, the card never needs to know which 
licenses it is certified to have. 


It is crucial that the publisher’s master public key and 
the procedure for checking the certificate and the pres- 
ence of the card are embedded in the software in such a 
way that the key cannot be changed and the check can- 
not be disabled. In general, this is not an easy task. The 
protection can always be removed by reverse engineer- 
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ing the code. In practice, however, obfuscation of the 
checking procedure can significantly delay the reverse- 
engineering process and the production of marketable 
copies. Section 6 describes some measures that make 
the marketing of the modified software less attractive af- 
ter the protections have been removed. 


We will now outline the mechanism for transferring li- 
censes from one card to another. Once the license is 
bound to a public key, it can be given to other keys by 
delegation. The key having a license simply signs a cer- 
tificate stating its willingness to give the same rights also 
to the key of another card. This kind of certificate with 
which one key delegates access rights to another one is 
called a delegation certificate. The signing is done with 
public-key cryptography. It is possible to use standard 
certificate formats and techniques (5, 2]. 


Unfortunately, this simple procedure is not quite 
enough; it would result in duplication of the license. Af- 
ter handing over the license, the first card must cease 
to function as a token. Furthermore, it must never sign 
another delegation certificate (at least not to delegate the 
same license). The simplest way to ensure this is to erase 
the private key from the delegating card. Erasing the key 
means that we must always transfer all licenses together 
to the same card and then discard the original card. 


Thus, license transfer comprises two steps: 


1. delegating the license to another card 


2. disabling the delegating card as a token. 


In principle, a license can be transferred an unlimited 
number of times. Every transfer adds a new delegation 
certificate to a chain that passes a growing collection of 
licenses from card key to card key. When the right to 
use a certain software package is verified, there must be 
a complete chain of certificates starting from a license 
certificates signed by the publisher’s master key and end- 
ing with the public key of the card that is currently in the 
smart card reader. In practice, the number of transfers 
for a single license will be very small (usually one). The 
licenses cannot be transferred onto previously disabled 
cards and every transfer accumulates all the licenses on 
two cards onto a single one. 


The cards need to have only two basic functions: proving 
the possession of a private key by responding to a chal- 
lenge and signing a delegation certificate after which the 
card disables itself. Further management of the certifi- 
cates is done outside the smart card. Sec. 4 details the 
transfer protocol. 


The idea of transferring licenses from one smart card 
to another bears resemblance to the transferable digi- 
tal cash of Pagnia and Jansen [12]. From the result of 
Chaum and Pedersen [4], we can infer that the growth of 
the license data with each transfer is inevitable. In our 
scheme, another delegation certificate will be appended 
to the license in each step. It is important, however, to 
note that the growing collection of delegation certificates 
is not stored in or processed on the smart cards. The 
smart cards act as tamper-resistant observers that guard 
against copying of licenses. This is equivalent to double 
spending prevention for digital money [3]. 


4 Protocol for license verification and 
transfer 


Each card has a unique signature key pair. The public 
part of the card key (CK) can be read from the card at 
any time while the private key is never exported outside 
the card. In addition to the keys, the card stores a card 
certificate signed by the software-publisher master key 
(PMK). The card certificate states that CK is the pub- 
lic key of an authentic license card. The certificate can 
be freely read from the card. Anyone knowing the pub- 
lic PM K can verify the certificate on the card and con- 
clude that this is an authentic license card approved by 
the software publisher. The PM K and the card certifi- 
cate will be used to ensure that licenses are transferred 
only to smart cards that reliably protect them from copy- 
ing. Every card has to store the authentic public PM Kk 
for verifying card certificates. A card certificate is of the 
form 


Spmx(CK, “is a license card key with production 
date”, date) 


(The notation Sx(M) means the message M signed 
with the key AK. Our view of the signature function 
is ideal. Implementations should follow accepted stan- 
dards such as PKCS [7].) 


The certificate contains the production date or serial 
number of the card. The licenses can only be transferred 
from older to newer cards. This ensures that cryptanal- 
ysis of old card keys or cracking the defenses of old 
tamper-resistant cards cannot be used for copying new 
software products. It should be noted that the card cer- 
tificates and the dates on them originate from the soft- 
ware publisher or trusted card manufacturers, the date 
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Private card key 


Card certificate 


« is a license card key, 
production date ##. 


Signed: PMK 


Public card key 


License card 









Co 


License certificate 


K has a license 
for software A. 
Signed: PMK 





Figure 1: A basic license card has a key pair and two certificates. 


stamps are compared against each other, and the com- 
parison is done on the tamper-resistant license cards. No 
clocks are needed on the smart cards and clocks in the 
user equipmentare not relied on. Therefore, the compar- 
ison of dates is reliable. As a secondary protection, the 
software checking the presence of the token should also 
ensure that the date on the card certificate is not older 
than the software itself. 


Normal cards originally hold only one license as they are 
sold in retail stores with software packages. The license 
is a certificate signed by the PM K that binds the right 
to use a certain software package to the C'K. The license 
certificate is of the form 


Spmx(CK, “has a license for”, software). 


Although it is not necessary to store the license infor- 
mation on the card, it is convenient to distribute licenses 
on the cards that come bundled with the software distri- 
bution media. This way, the software itself can be on 
identical media, e.g. printed CD-ROMs. For efficiency, 
it is best to read the card and license certificates from the 
card into the workstation only once when the software is 
installed and never refer to them on the card again. It is 
possible to ship several license certificates with a single 
card (e.g. stored ona floppy disk). This is practical when 
the publisher ships products directly to the users or when 
workstation manufacturers pre-install a standard set of 
software. 


In addition to carrying the certificates, the card can per- 
form two main functions: proof of identity and license 
transfer. The former means proving the possession of 
the private CK. The card does this simply by signing a 
challenge. 


Protocol 1 (proof of identity): 


Workstation — Card : 
“License card challenge”, N 


2. Card -+ Workstation : 
Scx(C License card response”, NV) 





The checking software first needs the public card key 
CK and the card certificate. Then, it can send a chal- 
lenge to the card and verify that the card is authentic. 
To decide if the card has a certain license, the software 
follows the delegation certificates to find a chain of dele- 
gation from PM K to CK. These certificates are stored 
outside the card and can be written into a file or onto a 
floppy disk for keeping with the card. 


The delegation certificates are created in the second 
main function of the card, the license transfer. All li- 
censes on the card are always transferred at the same 
time. After the transfer, the original card can be thrown 
away. 


The transfer protocol is very simple. Licenses on two 
cards will be combined onto one of them. The source 
card (the one to transfer from) must be the older card 
and the destination card (the one to transfer to) the newer 
one. Before the transfer, the workstation obtains the card 
certificate of the destination card. After that, the proto- 
col is between the workstation and the source card only. 
The destination card is not involved in the communica- 
tion. The delegation certificate produced in the transfer 
will be stored in the workstation and it will later be used 
together with the destination card. However, the desti- 
nation card does not need to know anything about the 
transfer and the certificate is never saved onto the card. 
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Protocol 2 (license transfer): 


Workstation > Source card : 
“Please transfer to”, CK", 
Spmx(CK", “is a license card key 
with production date”, date) 


The source card signs a certificate and 
erases its private key CK. 
Source card —> Workstation : 
Scx(‘I give all my licenses to”, CK‘) 





In the first step of the protocol, before delegating the li- 
cense to the public key C'K’, the source card checks that 
the key belongs to an authentic license card. It therefore 
needs the card certificate for CK‘. It also compares the 
date on the card certificate to its own production date to 
see that the destination card is the same age or newer. 


In step 2, the card signs a delegation certificate for CK'. 
The certificate is of the form Scx (“I give all my licenses 
to”, CK‘). After signing the certificate, the card perma- 
nently erases its own private key CK from its memory. 
After erasing the key, the card is not anymore able to 
perform Protocol 1, i.e. the proof of identity. This means 
that it is disabled as a license token. 


Having created the delegation certificate, the card re- 
turns it to the requesting workstation in Step 3 of the 
transfer protocol. After the transfer, the source card is 
useless and it can be thrown away. In order to protect 
against loss of certificates, the card certificate, the li- 
cense certificate and the new delegation certificate are 
still stored on the otherwise disabled card and can be 
reread an unlimited number of times. 


A crucial point for the smart card implementation is that 
signing the delegation certificate and erasing key pri- 
vate key must be an atomic operation. If the operation 
is interrupted, for example, by cutting power from the 
card, the card must either complete the signing and era- 
sure immediately after power-up, or it must return to the 
original state where the delegation certificate does not 
exist. Moreover, the production and storage of the del- 
egation certificate on the card must be reliable because 
the signing cannot be repeated after the private key has 
been erased. 


In summary, the protocol performs the two steps that 
make a complete transfer: delegation and disabling the 
old card as a token. In the workstation, the new dele- 
gation certificate will be combined with the ones both 


cards previously had. All these certificates are needed 
for use with the destination card (Fig. 4). 


5 On-line software distribution 


Although we cannot assume all customers or all work- 
stations to have Internet connections, an increasing num- 
ber of customers is willing to purchase software on-line. 
Two-way communication between the user workstation 
and the software publisher opens new possibilities for li- 
cense management. It is necessary for the same license 
management system to support both traditional shrink- 
wrap software sales and on-line commerce. 


When licenses are sold on-line, they can be personalized 
for each customer. The key to controlling the distribu- 
tion of the licenses is to bind each license to exactly one 
user workstation at a time. There are plans for incor- 
porating unique identifiers into the microprocessors in 
personal computers for this purpose. Because of pri- 
vacy concerns, it is not clear whether such identifiers 
will ever be implemented be all vendors. Some copy 
protection products compute a fingerprint of the hard- 
ware and software configuration to identify the worksta- 
tion [13]. Unfortunately, this may cause invalidation of 
the license when parts of the system are updated. 


In our system, the card key of a smart card is a unique 
identifier to which the licenses are bound. The same 
smart cards that are sold in retail stores can be used for 
on-line purchases. Instead of getting the licenses with 
the card, the customer buys license certificates for his 
card from the on-line store. If the particular workstation 
already has a license management card, the license cer- 
tificate will be issued to the public card key of that card. 
Most customers have recent cards e.g. from purchasing 
the operating system and, since the price of the smart 
card itself is low, empty cards without a license can be 
distributed free of charge. 


Protocol 3 (on-line purchase): 


Customer — Publisher : 
“T buy a license for”, CK, 
Spmx(CK, “is a license card key 


produced on”, date) 
2. Publisher — Customer : 
SpmuxK(CK, “has a license for”, software) 
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License card 


cK’ & 


License card 


ck & 


give all my 
licenses to CK’. 
Signed: CK 


Delegation certificate 


K is a license card key, 
production date ##. 
Signed: PMK 


K’ is a license card key. i’ has a license 
production date ##. for software B. 
Signed: PMK 


K’ is a license card key, 
production date ##. 
Signed: PMK 


K is a license card key, 
production date ##. 
Signed: PMK 


a 





 , — 


K has a license 


for software A. 
Signed: PMK 








Signed: PM 
fi Peal Ea 


K’ has a license 
for software B. 
Signed: PMK 


K has a license 
for software A. 
Signed: PMK 





License card 


mK & 





Figure 2: License transfer = signing a delegation certificate + disabling the source card. The certificates are stored 


outside the cards. 


The on-line store needs to see the card certificate to 
check that the public key C’K belongs to an authentic 
license card. 


The only limitation for this type of on-line sales is that 
licenses should not be sold to cards that are too old be- 
cause their keys might have already been recovered by 
pirates. (If the pirate knows the private key of an authen- 
tic license card, he can purchase one license on-line and 
delegate it to any number of cards.) If the card is older 
than some threshold time, the customer needs to obtain 
a new card and move licenses from his old card onto it 
before buying new software on-line. The threshold time 
for rejecting old cards can be adjusted for new products 
according to the experiences from earlier releases. 


Actually, it is not important how the software itself is 
distributed: on-line or on a CD-ROM or on some other 
medium. The distribution of licenses can be completely 
independent of the software distribution. 


On-line services open new possibilities for strengthening 
the security of the system. If the product includes parts 
or services, such as updates, that are delivered over the 
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Internet, the servers can check for the license before pro- 
viding the service. The on-line server will send the user 
workstation a challenge. The response from the smart 
card is sent to the on-line service along with the public 
key of the smart card, the license certificate or a chain of 
certificates from PM K to C’K, and the card certificates 
for all card keys in the delegation chain, The server can 
store fingerprints of the keys in the chain and refuse to 
repeatedly provide the same service for the same keys. 
Similarly, the same license should not be sold twice to 
the same card because it may indicate that the card is a 
clone. This improves the strength of the copy protection 
in case a pirate is able to recover the private key of a 
single card. Users of the pirated licenses will be refused 
on-line service. 


It is for the purpose of bookkeeping at the on-line servers 
that we retain all the card certificates in the license trans- 
fer. If on-line services are not available or the on-line 
server has a database of all valid card keys, it is not nec- 
essary to store the card certificates of the disabled cards 
after the transfer. It suffices to keep the one belonging to 
the active card. 
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6 Enhancing the copy protection 


Copy protection is never perfect. Therefore, we will 
consider ways of strengthening the protection. The ef- 
fectiveness of these techniques depends on the nature of 
the product and the environment where it is mainly used. 


The two most dangerous attacks against the copy protec- 
tion in our license management scheme are recovering of 
the private key from the smart card and modifying of the 
software to bypass the checking for the token. 


When on-line updates or other Internet services are an 
essential part of the product, the problem of recovered 
private keys is alleviated by having the servers remem- 
ber the keys for which the service has already been pro- 
vided (see Sec. 5). Professional pirates cannot produce 
fully functional copies even if they are able to crack the 
protections of a single card because users of the illegal 
copies will not be able to access the on-line services. 
This works because the cards have unique keys instead 
of one shared secret. Continuing the analogy to digital 
cash, the database of served card keys resembles double- 
spending detection by banks that keep track of spent 
coins. 


Another way of discouraging the purchase of pirated 
copies is to have the users authenticate the software. 
The person installing or using a pirated software pack- 
age should get a warning about potentially dangerous, 
unauthentic code. The warning can be implemented by 
signing the code with the publisher master key PM K 
or with another key held by the publisher. The public 
verification keys can be distributed on-line or with the 
operating system. If the pirates modify the software in 
order to remove the check for the license, the pirated 
copies inevitably fail the test for correct signatures. This 
kind of integrity check is beneficial even if copy protec- 
tion is not an issue: software distributed over the Internet 
should be authenticated in any case. 


Implementation of the integrity warning messages re- 
quires co-operation with the operating system or with 
a generic installation program. The warnings can nat- 
urally be avoided by modifying also these support pro- 
grams. However, most business users of software are 
probably unwilling to tweak their operating system ac- 
cording to the pirate’s instructions. Also, the embed- 
ded operating systems in special-purpose devices such 
as game consoles and multimedia terminals often can- 
not be modified by the user. 


Instead of completely disabling the check for the to- 


ken, pirates may try to modify the smart card reader or 
its driver software in such a way that several worksta- 
tions can share one reader. The challenges and responses 
could be transferred over the network between a single 
reader and a large number of verifiers. To prevent such 
modifications, the checking software should have direct 
access to the smart card reader hardware so that it can 
trust the responses to be from a local source. Sometimes, 
especially if the operating system consists of replaceable 
modules or layers, it may be impossible to prevent tap- 
ping between the card and the verifier. Even then, the at- 
tack is only possible if the modification to the operating 
system is available and if the user organization is willing 
to install the patches on all workstations. Other possi- 
ble defenses include binding the licenses to workstation 
identities and limiting the number and frequency of an- 
swered challenges per license. Such measures, however, 
imply unique processor identifiers, on-card timers, coun- 
ters, and much more complex protocols that are beyond 
the scope of this paper. 


There is one effective technique for checking the pres- 
ence of the token which requires some adjustment for 
our public-key protocols. That is, the software on the 
distribution media can be encrypted and the license to- 
ken should contain the key for decrypting it. If the soft- 
ware is never stored outside the computer memory in 
decrypted form, it cannot be loaded without the token. 
(Naturally, this is just a way of obscuring the check for 
the tokens. The program in the insecure computer mem- 
ory can be read and saved with special tools and skill- 
ful reverse engineering.) Dongles sometimes carry a se- 
cret key for decrypting the code [13]. If we want to use 
this technique in our license transfer scheme, we have 
to pass the decryption keys to the destination card and 
erase them from the source card as a part of the license 
transfer. The keys can be transferred by encrypting them 
with the public key of the receiving card. 


7 Preventing license theft 


New technology often creates new types of vulnerabil- 
ities that are beyond our prior experience. When the 
software licenses are bound to small, tangible objects, a 
new threat emerges: theft of licenses. And what is most 
disconcerting, the transfer protocol could be misused to 
steal licenses electronically over the network. Luckily, 
theft can be prevented with simple password protection. 


The physical theft of license cards may be a problem 
anywhere where untrusted persons have physical access 
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to the workstations. The standard protection against the 
theft of smart cards is that the card requires the user to 
enter a password after it is inserted into the reader. The 
card refuses to work unless activated with the correct 
password. This effectively prevents the use of stolen li- 
cense cards. The password can be distributed on paper 
with the card. For convenience, the users should be able 
to disable the password feature in environments where 
theft is not a major threat. 


Even with the password protection, there is still the dan- 
ger that someone removes the card not for his own profit 
but to cause damage to the owner. Vandalism is a prob- 
lem for public-access computers in places like universi- 
ties and libraries. The card could be protected by en- 
closing the card reader inside the workstation casing or 
by using lockable special-purpose readers. 


A more interesting scenario is that the thief transfers the 
license onto his own card. A hacker could even break 
into the computer from the network and invoke the trans- 
fer procedure without having physical access and with- 
out exposing himself to much danger of being identi- 
fied. Again, a separate one-time password should be re- 
quired by the card before the transfer. Since the transfer 
is activated only once for each card, passive sniffing for 
the passwords does not benefit an attacker. In theory, 
the hacker could take over the transfer process after the 
user has entered the password and replace the destination 
card certificate with his own. Therefore, license trans- 
fers should be done on a trusted workstation, preferably 
off-line. An alternative protection that prevents attacks 
from the network is a physical write-protect switch on 
the card that must be shifted to allow the transfer. 


8 Evaluation 


The main goal in the development of our license man- 
agement scheme was to make the use of hardware tokens 
user-friendly. In particular, we have solved the problem 
of smart-card juggling. Although the user must insert 
a smart card into the reader, it is not any more neces- 
sary to periodically switch between cards. Licenses of 
several software packages are transferred onto a single 
card. 


The license transfer is an extremely simple procedure 
for the user. He inserts the two cards into the smart card 
reader, the newer card first. (If the order is wrong, he 
is asked to reinsert the first card.) He may be asked to 
provide a floppy disk for backing up the certificates. 
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The system requires the user to have a smart card reader 
on every workstation and the license card must be in the 
reader for most of the time. Beyond the card reader, 
no changes to existing hardware (e.g. Internet connec- 
tion, secure processors or hardware identity numbers) 
are needed. After the initial investment in the read- 
ers, the marginal cost of protecting each new product 
is small. Since the certificates are stored and handled 
mostly outside the cards, the storage and computational 
capacity needed in the smart cards is bounded. 


We have seamlessly integrated shrink-wrap and on-line 
sales of software licenses. The license management does 
not require any changes to existing software distribu- 
tion channels. In particular, incorporating a smart card 
into shrink-wrap software packages does not increase 
the workload at retail stores or require users to have net- 
work connections. 


The security of the system relies on two non-trivial as- 
sumptions. First, the smart card must be tamper resistant 
in the sense that the private key cannot be recovered from 
the card. Recovering the key of even one card makes it 
possible for a professional pirate to sell counterfeit li- 
censes. With on-line distribution of licenses, the pirate 
must crack a new card when the previously cracked card 
becomes so old that the on-line store refuses to sell new 
licenses to it. If software is not sold on-line, the pirate 
must recover a new key for each new software product 
or version. It depends on the state of the tamper-resistant 
smart card technology how long it takes to analyze a 
card. Service can be denied to those users of pirated 
software who try to utilize on-line updates and services 
associated with the products. 


Second, the checking for the token in the software pack- 
age must be obscured in such a way that the check can- 
not be disabled. Since the public key of the software 
publisher (PM Kk) is used for the checking, one should 
not be able to change this key in the code. Like tamper- 
resistant cards, obscured software can be analyzed with 
time and resources. In this case, it is probably the eas- 
ier line of attack. We suggest discouraging the use of 
modified software by issuing warnings to the user. 


When these basic assumptions are satisfied, the license 
transfer protocol itself is fairly robust. The transfer pro- 
cess cannot be interrupted to prevent erasure of the old 
license because the private key is erased as soon as the 
delegation certificate has been signed. We state formally 
the claim that the protocols do not allow copying of li- 
censes (see the Appendix for the proof): 
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Proposition 1: The number of keys with valid licenses 


is at most equal to the number license certificates signed 
by PM K. 


Moreover, licenses are not easily lost because the del- 
egation certificates can be reread from the card at any 
later time and the certificates are backed up on the work- 
station hard disks or on floppy disks. 


In summary, the license management system prevents 
multiple use of one license and it increases significantly 
the work of professional pirates, Although the user must 
keep the license card in the smart card reader, it is much 
more convenient than having separate tokens for each 
product. 


9 Protocol extensions 


Our license management protocol can be extended in 
several ways to increase its flexibility for users. 


Although the protocol is fairly robust against accidental 
loss of licenses, there should be some off-line recovery 
mechanisms in case the license card is damaged or the 
delegation certificates are lost. The software producer 
can be generous with replacing cards and lost licenses. 
If a log is kept of the customers who receive a replace- 
ment certificate or smart card, the number of customers 
willing to cheat to get one extra copy of the product is 
likely to be small. 


Although we have designed the license transfer protocol 
with local transfer in mind, the protocol itself has no re- 
striction for remote transfer over a network. If this is im- 
plemented, the customer can transfer licenses over large 
distances without waiting to get the physical license card 
in mail. The remote transfer cannot be abused so that 
several remote users would pool to share a license (with 
at most one user at a time) because a new smart card is 
needed for each transfer. 


In order to have only a single card per workstation, soft- 
ware publishers must co-operate. All card must use the 
same protocol and meet the same standard of tamper- 
resistance. Fortunately, it is not necessary to have all 
publishers share the master key PM K. Instead, the 
products of each publisher can check for a delegation 
chain starting from its own master key. These publisher 
keys, however, cannot be used for signing the card cer- 
tificates because the safety of the cards affects all pub- 


lishers. For this purpose, another layer of delegation can 
be added: a trusted agency holding a master key that will 
certify card manufacturers’ master keys. The manufac- 
turer will include its certificate on the card and sign the 
cardkey CK with its own key. This allows accreditation 
of new manufacturers at any time. 


Naturally, the use of the delegation certificates for li- 
cense management is not restricted to smart cards. The 
same ideas could be used with any intelligent hardware 
tokens as long as the tokens are capable of processing 
public-key signatures and their cost is low enough so 
that they can be discarded. Different physical imple- 
mentations of the tokens can be mixed as long as they 
follow the same protocols. Non-discardable physical to- 
kens such as dongles and chips embedded in the com- 
puter hardware work well but licenses should be only 
transferred onto them, not from them. One possibility is 
to have one embedded token per workstation and to use 
smart cards only for license distribution. 


Finally, an alternative to having a card for each worksta- 
tion is to let each user carry a personal license card. That 
naturally leads to using the card as a general-purpose 
identifier for the user. Our protocols are equally well 
suited for many other purposes such as maintaining per- 
sonal key rings for smart-card locks. However, such ap- 
plications are beyond the scope of this paper. 


10 Conclusion 


We have described protocols for binding software li- 
censes to tamper-resistant smart cards, for transferring 
them between cards and for buying licenses on-line. 
There must be smart card readers at the workstations 
but no network connection or other changes to existing 
hardware are needed. The protocols support software 
distribution both through retail stores and over the In- 
ternet. The user can transfer licenses from several cards 
onto a single card so that juggling between several card 
in the reader is eliminated. The transfer protocol is easy 
and intuitive for the user. The smart cards must be able 
to process public-key signatures. In other respects, the 
protocols are simple both to implement and to analyze. 
Most of the data involved is stored outside the smart 
card. The protocols may also have applications in other 
system where smart cards are used for storing creden- 
tials. 
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Appendix (proof of protocol security) 


We consider the licenses for a single software product. 


Definition 1: A key CK has a valid license if the 
private part of the key C’K is unerased, and there is a 
card certificate signed by PM K and issued to the public 
part of C’K, and a certificate chain: 


a license certificate signed by PMK toC'Ko, 


a delegation certificate signed by CK to CK}, 
a delegation certificate signed by CK, to CKa, 


a delegation certificate signed by CK,_1 to CK, 
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such thatCkK,=CK. O 


This forms a valid license because the verifier checks for 
these conditions before allowing the use of the software. 
It is possible that & = 0, i.e. there are no delegation cer- 
tificates. We ignore the check for the other card certifi- 
cates (of CKg...CK,_1) and for the production dates 
because they have effect only if some other assumption 
is broken, 


Assumption 1: PMK only issues license and card 
certificates to authentic card keys. An authentic card 
key only issues delegationcertificates to keys with a card 
certificate. O 


Assumption 2: For every authentic card key C'K, ex- 
actly one of the following holds: 


1. CK has signed no delegation certificates. 


2. CK has signed exactly one delegation certificate 
and the private key CK has beenerased. O 


The second assumption follows from the policy of eras- 
ing the private key immediately after signing a delega- 
tion certificate. 


Proposition 1: The number of keys with valid licenses 
is at most equal to the number license certificates signed 
byPMK. O 


Proof: The subjects of license certificates (C’Ko) are 
always authentic card keys. An authentic card key only 
delegates to a key with card certificate and such keys are 
authentic card keys (Ass. 1). Consequently, all keys in 
the chains starting from license certificates are authentic 
card keys. The authentic card keys delegate to at most 
one other key and a key that has delegated is itself erased 
(Ass. 2). Thus, the certificate chains starting from li- 
cense certificates do not branch and only the last key in 
a chain can be unerased. 


If there would be more keys with valid licenses than 
license certificates, there should be some two valid li- 
censes whose corresponding certificate chains (Def. 1) 
begin with the same license certificate but end in two dif- 
ferent unerased keys. However, this is not possible since 
the chains do not branch and only the maximal-length 
chains end in unerased keys. 
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Abstract 


Conditional access (CA) systems manage chargeable 
content (e.g., movies). Traditional CA systems use a 
smartcard as a cryptographic component that decrypts 
broadcast content for authorized recipients. Since that 
approach protects content by protecting cryptographic 
keys, it has two inherent weaknesses: It relies on the 
smartcard to protect universal secrets (i.e., the broad- 
cast keys); and it cannot protect content from redistri- 
bution. This paper describes a non-cryptographic con- 
ditional access system, where instead of protecting 
content directly, the content’s identity is inserted as a 
watermark in the content and the CA smartcard is used 
as a licensing authority to authorize the display device 
to display watermarked content. This approach places 
a lower security burden on individual smartcards, and 
protects against the use of redistributed content. 


Keywords: Authentication, authorization, conditional 
access, copyright protection, licensing, smart cards, 
trust management, watermarking. 


1. Introduction 


Conditional access (CA) systems control access to 
chargeable content. This content includes both data 
and entertainment products such as movies or music. 
The content may be delivered in many ways, including 
broadcast from satellite or a local broadcaster, trans- 
mitted over cable or the Internet, or delivered by fixed 
media, such as a DVD. Billing policies also vary 
greatly: content may be sold as part of a subscription 
such as premium movie channels, by the unit like pay- 
per-view movies, or incrementally as in a stock ticker 
that is charged by access time. 


Traditional CA systems protect chargeable content 
cryptographically. The primary function of a CA sys- 


tem is to report content access to a billing system, and 
to prevent unreported access to content. To force con- 
tent to be accessed through the CA system, content may 
be encrypted using cryptographic keys known only by 
the CA system. In that model, encrypted content is 
broadcast by a headend system and accessed through a 
CA smartcard on the user’s set-top-box (STB, e.g., a 
TV or cable tuner). Accesses are reported to a backend 
billing system. The distribution of content keys is 
managed by a key management system (KMS) that lets 
CA smartcards leam the keys needed to decrypt con- 
tent. 


Cryptographic CA systems require the CA smartcard to 
protect content keys. Since efficient broadcasting re- 
quires universal shared secrets (i.e., there is a single 
broadcast data stream for any content), each smartcard 
must be trusted to protect universal secrets. This is a 
severe security burden for the smartcard. The pirate 
may use significant resources to compromise a single 
smartcard, and leam the keys necessary to decrypt 
content. Those keys are useful to all recipients of the 
content. Furthermore, CA systems are attempting to 
solve an inherent paradox: How is access to content 
enabled yet still controlled? The STB must have access 
to the unencrypted content. The pirate may attack his 
STB, obtain the content, and redistribute it. This threat 
has typically been called copy protection, and is not a 
CA threat, as long as redistribution is expensive. 


We are concemed about CA in an environment where 
redistribution and storage of content and keys is cheap. 
Although this is not yet true for high quality video, it 
will be true, and it is appropriate to design systems that 
are resistant to this threat. Notice that display devices 
will always have to display free video, at least from 
camcorders. So the pirate can redistribute a pirated 
movie as a home video. 


Our proposed architecture uses the CA smartcard as a 
licensing authority, instead of a decryption device. 
When granting authorization, a CA device may also log 
content access, so the access may be billed for. If dis- 
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play devices required authorization to display certain 
content, and would refuse to display the content in the 
absence of appropriate authorization, content would be 
secure independently of how it was delivered to the 
display device. The assumption here is that display 
devices like monitors are expensive and difficult to 
manufacture and service, and that pirates will not be 
able to compete in that market. 


In this architecture, instead of protecting against the 
copying and redistribution of the content, we prevent 
unauthorized access to the content. This architecture 
places the security where it belongs, at the customer of 
the pirate, who will be unwilling to spend significant 
resources to defeat the system. In contrast, in crypto- 
graphic copy protection, the pirate can leverage off of 
his investment, without requiring further investment by 
the consumer. 


This paper is organized in the following way: Section 2 
presents an overview of traditional CA systems. Sec- 
tion 3 presents the non-cryptographic CA architecture. 
Section 4 describes related work. Section 5 presents 
some concluding remarks. 


2. Cryptographic CA Overview 


A model of a CA system is illustrated in Figure 1. No- 
tice that content keys need not be delivered with the 
content, although they may be, and that the backend 
billing system may be independent of the headend too. 


Bs 


Billing System 


Ge p>) 


Content 


Figure 1: Model of CA Infrastructure 


The billing system has two security roles: one is to 
instruct the key management system which keys should 
be sent to individual CA smartcards, and the other is to 
upload logs of key use from CA smartcards. These two 
functions correspond to advance billing for subscription 
services, and credit-type billing for pay-per-view serv- 
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ices (i.e., where services are used before they are paid 
for). 


The CA smartcard, which is present in every user’s 
house, must protect cryptographic keys that are univer- 
sally useful. That is, the keys that a CA smartcard uses 
to decrypt content are equally useful to other recipients 
of the broadcast. If those keys are compromised and 
distributed, other recipients of the broadcast may use 
the keys to access content for free. In particular, since 
there is more content than keys (e.g., content takes up 
more bandwidth than keys), a pirate can leverage off of 
the original broadcast, only redistribute keys, and make 
money at the broadcaster’s expense. 


In cryptographic CA systems, the CA smartcard is a 
hardware device that protects keys. The security of 
this hardware decreases over time, because its design 
flaws become known, and physical attacks against it 
become cheaper. Furthermore, the pirate may be able 
to amortize the cost of attacking a single smartcard over 
the sale of many counterfeit smartcard. This suggests 
that the CA smartcard be renewable, so the security of 
the CA infrastructure may evolve over time. The chal- 
lenge is to design an infrastructure that admits increas- 
ing security at low cost over a long lifetime. 


3. Non-Cryptographic Conditional Access 


If content redistribution is easy, there is no real point in 
protecting content up front, by encryption, for example. 
Imagine that bandwidth was very cheap: HBO may 
have a single customer, a pirate, who redistributes con- 
tent to everyone else. Service providers cannot sustain 
businesses in such an environment. In this section, we 
describe a possible direction for protecting content in 
such a threat environment. 


Notice that securing the input ports in the playback 
(display) device is not an adequate solution, since cus- 
tomers must always be able to play home-generated 
content (like output from a camcorder) and the pirate 
could redistribute content as if it were generated by a 
camcorder. We must prevent chargeable content from 
masquerading as free content. Even if in the future, 
camcorders would mark their content in such a way that 
chargeable content would not carry the free-content 
markings, this alone would not address the playing of 
legacy content generated by existing camcorders be- 
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cause a pirate could redistribute new chargeable content 
in the old home-generated content (unmarked) form. 


The current reality of smartcard technology forces us to 
acknowledge that CA smartcards are not completely 
impervious to compromise. This together with the fact 
that at some point the plaintext content data is routed 
through the non-renewable playback device, forces us 
to focus on preventing successful use of the pirated 
content by potential customers of the pirate, rather than 
on preventing acquisition of the pirated content in the 
first place if we treat the content redistribution problem 
as a surmountable impediment. We want to take ad- 
vantage of the fact that even if the pirate and his cus- 
tomers want to consider the use of pirate-provided non- 
compliant playback devices, the sophisticated monitor 
technology in display devices imposes significant barri- 
ers to entry for small- to mid- scale piracy operations. 


Assume that the analog content itself can be water- 
marked in some robust way at authoring time, so le- 
gitimate playback devices will detect the watermark. 
Assume furthermore that the pirate cannot remove this 
watermark without significantly degrading the quality 
of the viewing experience. Watermark removal is usu- 
ally done by corrupting the content, or by comparing 
two instances of the content with different watermarks. 
This latter attack need not be enabled in this approach, 
since all instances of the content will have the same 
watermark (i.e., watermarking is done here for play- 
back control purposes, and not for tracing the source of 
unauthorized distribution). Unlike “fingerprinting,” in 
this approach the content is watermarked at authoring 
time. 


Assume that each legitimate playback device (i.e., TV 
monitor) is bound to a limited set of CA smartcards, so 
that it will refuse to accept critical commands from any 
smartcard which cannot authenticate these commands 
as being generated by a smartcard in the distinguished 
set. A playback device may be bound to a smartcard by 
receiving a binding certificate signed by a recognized 
binding authority that binds the playback device to the 
smartcard. The binding certificate gives the playback 
device permission to trust responses from the specified 
smartcard. The playback device need not be authenti- 
cated to the smartcard: That is, the smartcard will sign 
authorization requests from any playback device. 


Notice that this binding between a playback device and 
a smartcard need not rely on the playback device hav- 
ing an externally discernible identity. For example, the 
playback device may issue a randomly generated bit- 
string, where the concatenation of this bit-string with 


the public key of a smartcard with which the playback 
device is allowed to communicate, is signed by the rec- 
ognized binding authority. 


To play watermarked content, each legitimate playback 
device requires authorization from the CA smartcard 
each time it encounters an embedded watermark signal 
which differs from the one just previous. At the onset 
of attempted content play, the first embedded water- 
mark signal always results in an authorization request. 
If this compression of challenges based on limiting 
authentication requests to deltas in the embedded sig- 
nals proves to be ineffective when processing content 
because changes occur too frequently, either the 
authorization device or the display device may go into 
alarm condition. The authoring process must embed 
the watermark signals with sufficient frequency so as to 
satisfy the most demanding playback devices. 


Even if there is no change in the embedded watermarks 
detected by the playback device, after a certain amount 
of viewing as determined by the appropriate metric of 
say, time or footage, the playback device may require 
an authorization from the CA smartcard if play is to 
continue. The CA smartcard does not need to process 
or even receive the entire content stream, but rather 
only the embedded information from the watermarked 
snippets the display device detects. So instead of de- 
crypting content for the TV monitor, the CA smartcard 
becomes an authorized licensing device. The legitimate 
playback device inspects content to see if a playback 
license is required, and the playback device refuses to 
play marked content if no license is presented. 


The watermarking of the content done during authoring 
may be done without regard to the billing infrastructure 
as long as the embedded signals differ across content so 
as to allow proper granularity when reconciling the 
billing process. If every title is marked distinctly, this 
will allow for later arbitrary assignments of billing 
units. 


Freshness considerations must be addressed so that 
presentation of licenses or authorizations by the CA 
smartcard cannot be effectively replayed so as to cir- 
cumvent appropriate billing for multiple viewings of 
the same content. For example, the playback device 
may include a random number along with the water- 
mark in the authorization request.. 


Compromise of this system requires the pirate to cor- 
rupt the watermark while still maintaining product 
quality, or produce playback devices that ignore the 
watermark, or compromise individual customers’ CA 
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smartcards. This should be considered an evolutionary 
approach to security, in that as watermark technology 
improves, new chargeable content can be released with 
the newest watermarks embedded as well as with the 
more vulnerable previous types of watermarks [9]. 
This allows for backwards compatibility with a popula- 
tion of display devices which shrinks as a percentage of 
the customer base of compliant devices as new more 
fully-featured display devices continually enter the 
marketplace. 


The binding authority is essentially a certification 
authority and many techniques are known for prevent- 
ing a single source of compromise for signing opera- 
tions. For example, a hierarchy of signing authorities 
may exist so the root key is used infrequently [Error! 
Reference source not found.]._ Furthermore, any 
signing operation may really be the result of multiple 
signing operations, so the compromise of a single ma- 
chine does not compromise the combined signature 
operation [Error! Reference source not found.]. Fi- 
nally, via signature schemes using “proactive” secu- 
rity, the multiple signing operations must be temporally 
related, so the compromise of a sufficient number of 
the individual signing operations must be done within a 
single window, in order to compromise the signature 
operation [Error! Reference source not found.]. 


4. Related Work 


Watermarks [2,9] carry an embedded signal within the 
desired signal and have been part of proposed solutions 
for many forms of copyright control, in particular copy 
protection. For example, a movie may carry a water- 
mark that instructs a VCR that it is not a recordable 
signal. The focus of such work has been copy protec- 
tion and not conditional access. 


Watermarks differ from fingerprints [1]. Fingerprints 
are signals in content that enable tracing information 
about the particular use or instance of the content (e.g., 
the name of the purchaser). Fingerprinting must be 
resistant to collusion, since an attacker may compare 
and combine different instances of the content. In our 
application, however, a particular content will have a 
single signal representing its billing ID. 


Linnartz [7], Linnartz, Depovere, Kalker [8], and Ep- 
stein [3] also discuss watermarking in the context of 
copy protection and conditional access. 
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[8] differentiates between playback control and re- 
cording control, where a pirate may disable watermark 
checking functionality within his own hacked recorder 
while finding it more difficult to produce content which 
plays back on standard (i.e., compliant) players. When 
dealing with the conversion from “one-copy” to “no- 
more-copy,” the authors do not want to provide a hook 
for hackers to break the system. Their proposal also 
addresses “never-copy” and “free-copy” (i.e., no wa- 
termark) material. 


They utilize electronic recognition of the storage me- 
dium (ROM vs. RAM), a “physical mark” P embedded 
on the disc which cannot be read or recovered exter- 
nally of the drive, and authorization tickets T. One 
goal is to prohibit playback of “never-copy” content 
from non-original media. During mastering of the 
ROM disc, the manufacturer performs the operation 
P=F(U) where U is a seed provided by (and only 
known to) the content owner and F is an appropriate 
one-way function. It is possible to have the construc- 
tion of P from U designate specific publishers through 
appropriate design of the function F. It is intended that 
the physical mark reserved for ROM content is hard for 
a casual copier to insert on RAM discs. 


It is claimed that a pirate publisher attempting to write a 
particular P in order to make a bit-exact copy of a copy- 
righted disc must tamper with the DVD press (which he 
may not own) if the press expects to be given the value 
of U which is not known to the pirate. According to 
Linnartz [7], one realization of such a physical mark P 
is the "wobble groove" in optical disks. If a disc con- 
tains a P reserved for professional content, and the 
content contains a watermark W, then playback re- 
quires that: W=F(P) is satisfied in the case of never- 
copy; that the validation ticket T is present and that 
T=F(P) and W=F(F(F(T))) are satisfied (where F(T) 
replaces T at the output of the drive) in the case of one- 
copy; that W=F(T) is satisfied in the case of no-more- 
copy. Playback is also allowed if the disc contains a 
physical mark reserved for recordable media and the 
content contains a valid W which is used for profes- 
sional recording and the validated one-copy T is pres- 
ent and W=F(T). During recording, the compliant re- 
corder passes the ticket through the one-way function F 
before transferring it to disc. Recording of copyrighted 
content is allowed only if W=F(F(T)). 
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5. Conclusion 


This paper presented a non-cryptographic CA system 
that protects content both against conditional access 
(initial purchase) threats, and copy protection (redistri- 
bution or repeated access) threats. The CA smartcard 
functions as a license authority that is able to authorize 
display devices to display protected content. Since the 
display device will only accept authorizations from the 
paired CA smartcard, the pirate cannot build a counter- 
feit licensing authority based on his smartcard and sell 
it to his customers [4,6]. These CA smartcards need 
not contain universal (system-wide) secrets, making 
them less attractive security targets. 


The efficacy of this system depends upon both the ro- 
bustness of watermarking and the prevalence and ro- 
bustness of display devices that detect watermarks and 
require authorization. How can this detection and 
authorization capability become standard in display 
devices? One technique is for it to be bundled with 
licensed technology that is a desirable feature or to 
make it part of a being a compliant product (e.g., in 
DVD systems, CSS security is part of the DVD specifi- 
cation). 
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Abstract 


This paper presents a solution to how a smartcard can be 
used to sign data in a hostile environment. In particular, 
how to use a smart card to make a signature on data when 
the machine to which the smart-card reader is attached 
can not be trusted. The problem is solved by means of a 
verification server together with a substitution table and 
a one-time pad; it is argued that lacking a trusted channel 
from the card, our solution is minimal. 


An invalid signature (a signature on data not intended 
to be signed) can only be made if the online server col- 
ludes with the machine the user is using. In all other 
circumstances, only a denial-of-service attack is possi- 
ble. The realization is applicable in practice, but slightly 
awkward. 


1 Introduction 


It is difficult to digitally sign data in a hostile environ- 
ment, even armed with a smart card that can create dig- 
ital signatures by means of some public-key technol- 
ogy [3]. Assume a user P sitting in front of a machine 
M with the smart card residing in a smart-card reader 
connected to M. If P wants to sign X, he has no means 
to verify that M actually gives X to his card; thus, P 
can not use the card without trusting M just as much as 
he trusts the integrity of the card, in which case he could 
use VV to sign rather than involving a smart card in the 
first place. 


The problem is that there is no authenticated “channel” 
from the card to the user. The card is unable to “tell” 
P what it is about to sign, and P can not verify that 
X has been received for signing [1]. The problem is 


well known [4, 14]. Authenticated channels can be ob- 
tained by means of, for example, more powerful hard- 
ware, such as contemporary PDAs. With this type of 
hardware, integrity is obtained since the PDAs have a 
(small) display on which X can be shown. However, 
smart cards are prevalent and we seek a solution using 
this technology. 


In general, data integrity relies on either secret informa- 
tion or authentic channels [7]. In other words, when us- 
ing smart cards without any authentic channels, some 
sort of secret information is needed. 


There are many settings where one might desire to sign 
data with a smart card, where the environment might be 
hostile. For example a point-of-sale terminal, or during a 
visit to an “Internet café”. Using a computer laboratory 
at a university is another example. In general, any en- 
vironment where one does not want to include M in the 
trusted computing base (TCB), for whatever reason [13]. 


The paper is outlined as follows. Section 2 is concerned 
with describing the system and our solution. Then, in 
Section 3, our protocols are shown and analyzed. Sec- 
tion 4 discusses related work. In Section 5 we present 
conclusions and give directions for future work. 


2 Overview 


This paper examines a particular—albeit common— 
setting where smart cards are employed. The general 
idea is that the user P has some data, an email perhaps, 
that he wants to sign, using the secret key stored in his 
card. He would instruct the software running on M to 
send the data to the smart-card reader, insert his card, 
and having the signature returned in order to be attached 
to the email. The problem is that M might give any data 
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to the card, and the card will sign. Unless P can ver- 
ify public-key signature in his head, he has no means to 
judge whether / is trustworthy or not. 


In fact, what seems to be a single problem really poses 
three distinct challenges: 


1. How can P ensure that the correct data has been 
signed? 


2. How can P verify that the signature is valid? 


3. Is it possible for a third party to conclude that P has 
verified that the correct data has been signed? 


The last is required if the signature P makes with his 
card is to have a non-trivial value. 


Concerning the first question, only P knows the answer 
to this, since only he knows what he intended to have 
signed; the fact that M also happens to know is of no 
relevance to us because M is not trusted. The user must 
thus be involved in providing an answer to the first ques- 
tion. Or, in other words, no solution to this problem can 
be envisioned without involving the user in some way, 
after the signature has been made. 


In a realistic scenario, we can rule out the possibility of 
P verifying the signature himself. This implies that a 
third party must verify the signature itself. Such a third 
party should take the form of an online service, in or- 
der to better enable the user to timely obtain an answer 
the second question. This, however, raises a new obsta- 
cle: How can this online service, called O, communi- 
cate with P over a channel that provides integrity? Our 
contribution is a working method to solve this particular 
problem. 


Turning now to the third challenge, it will become evi- 
dent that P can sign a certificate that, together with the 
credentials our solution creates as it progresses, enables 
others to conclude that the data indeed was signed by 
P’s card, with P’s consent. It might be worth noting 
that we are only interested in signing. P is unable to 
encrypt anything on his smart card without trusting M. 
That is, secrecy can not be obtained at all in the setting 
we describe. 


Our solution consists of three parts, an on-line service, a 
small one-time pad (an OTP) and a shared secret. In the 
following we will describe how some data is signed by 
means of a smart card in a hostile environment (details 
are given in Section 3). We use the notation from the 
BAN logic [2], 


1. The machine &™ is not trusted. Thus, // is not the 
logical sender or recipient of any message (even 


though the actual hardware will be used to send 
messages). From a logical point of view, M is part 
of the communication infrastructure. In this light, 
the only principals of interest are the user P, his 
smart card C’ and the on-line service O (to be de- 
scribed below). 


. The user has some data X, which typically is a 


string of characters (j.e., a text). P inserts his card 
(into the smart-card reader attached to /) and in- 
structs M to transfer the data to the card. The card 
is then instructed to sign the data it received. 


be PSC OX 


. The card accepts the message and signs X, creating 


{Xx} K5 Notice that C’ has no means to verify that 
X actually originates from P. As mentioned above, 
two questions must be answered: 

(a) Is the signature valid? 

(b) Has the correct data been signed? 


The online service can be used to verify the signa- 
ture’s validity; the signed data is sent to O. 


2, C30: {X} pot 


. The crux of our solution is that O can send back 


to P atransformation f of the data it has verified. 
Assume that P and O share a small secret one-time 
pad and a secret number. After verifying the signa- 
ture on X, O will create two new message as fol- 
lows. 


Using the one-time pad, a new message Z = f(X) 
is constructed, and sent to P. 


3:3 OW P: Z 


Z is thus the message X transformed for integrity 
under a one-time pad. We will discuss this transfor- 
mation below. 


If the signature is valid, O constructs a certificate 
asserting this fact. The certificate is sent to a public 
server of some sort. We call this server S, its exis- 
tence is only for convenience and might very well 
be O itself. 


A random number Y is associated with each one- 
time pad. Y is known only to P, but H(Y) is 
known also by O. If O finds that the signature is 
valid, O will sign a certificate stating this fact; the 
certificate will include H(Y). By releasing Y, P 
proves that he accepts the signature. 


4 0-48: {C,X,H(X,H(Y))}q=1 
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5. When Z is received by P, he can without much ef- 
fort (and without using M to anything but display 
Z) verify that Z = f(X). Since Z is a transfor- 
mation of X, P can conclude that the content was 
what he intended to sign, and that his trusted server 
O has verified the signature. P now releases Y by 
sending it to S. 


5: P+S: Y 


To sum up, O verifies the signature made by C’, and P 
acknowledges the actual text by releasing Y. 


Up to this point we have used logical messages. If we 
look at the actual implementation we find eight mes- 
sages being sent over various channels; see Figure 1. 
The messages can be described as follows: 


Message1: P-+»M : X 

Message2: M—>C : X fromP 

Message 3: C+ M {X} x1 

Message 4: M -+O {X} x1 from C 
Message 5: O-+S {C,X, H(X,H(¥))}ic-1 
Message 6: O- M (X)orp 

Message7; M—+P : (X)orp fromO 
Message8: POS :; Y 


Messages 6 and 7 contains the string of digits O has con- 
structed based on its copy of the OTP. Since the OTP is 
secret, the string is X combined with a secret. In BAN 
such a construction is denoted as (X orp. 


Section 3 gives a detailed description of the small one- 
time pad that is required, a closer look at the messages 
that are sent and, most important, a careful analysis of 
the logical meaning of each message and of the certifi- 
cates that are required to conclude that X was signed by 
C with the consent of P. 


3 Signing 


This section starts out by presenting the details of the 
one-time pad. Being small it is suited for practical use; 
Section 3.1 discusses it. Section 3.2 is concerned with a 
theoretical analysis of the certificates and credentials re- 
quired to assert that a signed statement froma smart card 
logically originates from the user that control the card. 
In Section 3.3 we discuss the trusted computing base of 
our solution. Section 3.4 describes the implementation 
status, and gives a preliminary performance analysis. 
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3.1 The one-time pad 


We assume that P does not have any significant compu- 
tational resources at hand (M can not be trusted). Since 
it is unreasonable to assume that any user can verify dig- 
ital signatures without the help of a computer, we must 
thus construct a secure channel from O to P, on whicha 
message can be sent. That is, P needs to receive from O 
some information that convinces him that the correct text 
was signed. This information must be a function of the 
message X in order for P to know that the correct text 
has been signed. In addition, P must be convinced that 
the message he receives comes from O. Taken together, 
the channel we are about to construct must provide au- 
thentication (since authentication implies integrity [7]). 
Clear-text attacks are indeed a threat since M knows X. 


If, on the other hand, XY was unknown to M then P and 
O could share a list ZL of random numbers, each number 
L;, of L being as long as X . O would verify the signature 
on X, calculate Z = X + LD; and send the result to P. P 
would be able to calculate Z — L; and verify that the card 
had signed X. This cipher would be perfectly secure [9]. 


In our system, each OTP contains two small tables. The 
first contains random numbers, as one would use to cre- 
ate a one-time pad. However, in our case X is known, 
and this procedure alone offers no integrity at all. This 
is so because if ’A’ and a random number yields 12 then 
*B’ must have yielded 13. We overcome this problem by 
incorporating an additional table. It is a permutation of 
the characters; we denote this a substitution table. 


We now describe the OTP used by P and O. In the 
current implementation, the alphabet available to P are 
all the upper-case characters, space (denoted as ‘_,’), dot 
(‘.’), the digits and the two symbols $ and @; 40 char- 
acters in all. These characters are matched with a table 
of random numbers, assigning a random number to each 
character. Appendix 1 shows two examples of tables; 
each has six rows: 


Letter: The alphabet available to users 


Subst: The substitution table; each character from the 
alphabet is replaced by the corresponding number 
from the substitution table. 


X: In this row the user writes his message 


OTP: The number representing each character is added 
(modulo 40) to the corresponding element in the 
One Time Pad. 


Z: The result. 


Y: A secret number, see below. 
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Figure 1: The protocol run 


When P receives Z from O, he would want to verify the 
result. In order to do so, he proceeds as follows. 


1. Count the number of characters in the message, and 
prepend this number (as a string) to the message. 


2. Write the string in the table (in the row marked X) 
above the random numbers. 


3. For each character, add the ordinality of the charac- 
ter (taken from the substitution table) with the ran- 
dom number. The addition must be done modulo 
40 (the number of characters). 


An example of a table which is filled in is shown in 
the Appendix. The string “GIVE TAGE@ACM.ORG 
$500.” is encrypted for authentication. 


If P sees that Z indeed is the correct transformation of 
X, he will release Y. The certificate generated by O 
contains H(Y), but Y is only known to P. In other 
words, by releasing Y, P makes it known that he sup- 
ports the certificate issued by O. 


3.2 Theory 


The security of our system hinges on three properties. 
The first is that one component in each sum is a random 
number. Randomness ensures the resulting list of num- 
bers are random. No amount of calculation or number 
of previous messages can give information necessary to 
alter the text. Second, each OTP and substitution table 
can only be used once. Third, text can not be appended 
to the string. 


Obviously, the length of the string that can be trans- 
mitted (and verified) in this manner is restricted by the 
length of the pad. However, the pad can be made as 
long as one desires and the amount of work to verify a 
message increases linearly with length. Another way to 
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increase the task of verification is to increase the alpha- 
bet length (now being 40). If this length is increased, 
the OTPs and corresponding substitution tables must be 
increased accordingly. 


We have described how a user P can sign a message; 
we now describe how a receiver verifies that a signed 
message is valid. Assume a user Q receives a message 
(Yo {xX} Ko! 1) from P. Assume furthermore that Q be- 
lieves that Cc belongs to P. Upon receiving the message, 
Q contacts S and asks for the certificate that O should 
have generated. Obtaining it, Q has all he needs to con- 
clude that X was signed by C, that O has verified that 
the signature was in order, and that P has verified that 
the correct data was signed. The four datums that are 
available to Q is shown in the left column of Table 1. 
Informally, the fact that P has released Y is proof that 
P has verified the signature. We will now give a more 
formal view of the system, using the theory from [6]. 


If Q is to act upon X he would need a certificate, signed 
by P (or a principal Q believes speaks for P), assert- 
ing that possessing the four items together vouches for 
the conclusion that X originates from P. Since M is 
not trusted, P does not control C’, and the assumption 
C = P is unwarranted. The intention of P is that no- 
one will hold him responsible for any message X unless 
the following conditions are met: 


e X is signed by C. 
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e The signature made by C is verified by O. O must 
say that C' have said X. 


e O must tie (the secret) Y to the signed message. 


This enables P to accept the signature by releasing 
Ye 


e Y is available. 


All this is captured in the following certificate 
P says (CA O|C AO|Y) > P (1) 


Since Y is secret, Q is unable to satisfy the certificate 
(1) unless P releases Y. In practice, S could in addition 
act as an on-line verification for the validity of C' in that 
P would make C issue C' says (S|C A C) => C, see [6] 
for details. 


With these credentials, the axioms and interference rules 
set forth in [6], it follows that P says X. Note that the 
use of Y give the message the properties of a transac- 
tion authentication as defined in [7]; message authenti- 
cation and the use of time-variant parameters (timeliness 
or uniqueness). 


3.3. Trusted Computing Base 


As can be seen from (1) it is a prerequisite for certifi- 
cate verification that O says that Y says X. However, P 
does not want to include O in his TCB. O has not been 
given Y by P, but rather H(Y). When O quotes Y as 
saying X it might turn out that O is mistaken; this is in 
fact correct, in the cases where M, for example, mounts 
some attack. In other words, when Q collects creden- 
tials he might or might not be able to locate Y. In such 
a situation there are two possibilities: Either P has not 
released it (he has detected an attack) or Y has been de- 
layed or deleted as part of a traditional denial-of-service 
attack. Since P is at the mercy of /, there are no means 
to defend P against denial of service. 


O isa trusted third party in that P trusts O to act accord- 
ing to the protocol (not to certify that a signature is good 
if it is not). On the other hand, O is not able to deceive 
P without colluding with M. When O and M colludes, 
M can feed a false message to the card and let O send 
an erroneous message back to P. The important issue is 
that alone, O can not conceive P. In the same manner 
as O is notin the TCB, neither is S, nor C’. No principal 
is in a situation to make P release Y, which will erro- 
neously make (1) is true, without colluding with some 
other principal. 


3.4 Performance 


The system described is not yet fully implemented, al- 
though the infrastructure is; this includes a verification 
server, certificate and signature handling, and a cryp- 
tographic strong random number generator. We have, 
however, done preliminary performance tests using pre- 
defined OTPs and substitution tables. 


Experiments show that verification is initially done at a 
speed of approximately 7-8 seconds per character. How- 
ever, speed increases as one gets accustomed to the cal- 
culation. Experienced users spend approximately 3-4 
seconds per character. Slightly slower than typing, but 
in our opinion worthwhile. 


4 Related work 


Our solution is basically a Message Authentication Code 
(MAC). MACs are well covered in the literature, see for 
example [10, 7, 11]. However, most MACs are com- 
putationally intensive. Most types of MACs, such as 
MDS [8], are surjective, and require some computation 
to be secure (mapping one language onto a smaller while 
being a one-way function). 


The use of unconditionally secure MACs are described 
in [11, Chapter 10] with the use of orthogonal arrays 
(OAs). These OAs seems, however, to be infeasible to 
work with for human beings compared to substitution 
tables and OTPs that only require the use of elementary 
arithmetics. 


Authentication by means of a secret one-time pad is an 
old invention [5]. In this article, we have combined the 
one-time pad with the release of a secret to authenticate 
that the verification of the signature. 


5 Conclusion 


We have shown that users can achieve secure authenti- 
cation to messages signed with a smart card in hostile 
environments, using a partial trusted verification server 
together with a substitution table and a one-time pad. 
The applicability lies in that short messages with small 
character sets. 
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5.1 Future work 


We are working on implementing the system described 
in this paper, using Cyberflex Open16K smart cards! 
that run a Java VM, based on the Java Card 2.0 speci- 
fication [12]. Since these cards come without a copro- 
cessor (for efficiently doing computations on large in- 
tegers), signatures made with public key schemes such 
as RSA or ElGamal would be hard to implement effi- 
ciently. We are looking into this issue. In addition, we 
are also working on eliminating O from the protocol by 
storing OTPs and substitution tables on the smart card 
itself (this would require about 100-150 bytes of storage 
capacity for each OTP/substitution set). Making the ver- 
ification process easier for end-users is also prioritized; 
using arrow keys to decrypt the message from O may be 
a workable solution. This is not a new idea; the use of 
arrow keys for decrypting OTPs was suggested in [14] 
and was based on the insertion of ‘+’ and ‘nextdigit’ 
operations described in [1]. 


A way to eliminate the awkwardness of using OTPs and 
substitution tables would be to insert a channel between 
O and P for Message 6 in the protocol run. A mo- 
bile telephone could be used for this purpose, where O 
sends X and Y to P through, for example, the GSM 
network. P would then see that the message received on 
the phone’s display corresponds with the message that 
was originally written by P. A drawback here is that 
P and O must share the secret Y, since M could oth- 
erwise send X to P (through GSM). This implies that 
P must trust that O does not release Y until P does it. 
This drawback, combined with that O can no longer be 
eliminated from the protocol, would probably not detract 
from the fact that P no longer needs to do substitutions 
and arithmetics in his head (or use arrow keys). 
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Appendix 


Example OTP and substitution table 





23G6G6%r1VERE,TAGEBAC Me ORE 





| ore | 31 25 08 32 02 16 368 18 19 13 17 01 37 38 20 24 00 33 10 01 24 34 37 11 01 OS 08 14 15 29 03 03 18 39 30 OS 10 22 24 14 
a eee 
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Abstract 


We present an authentication protocol that allows a 
token, such as a smart card, to authenticate itself 
to a back-end trusted computer system through an 
untrusted reader. This protocol relies on the fact 
that the token will only respond to queries slowly, 
and that the token owner will not sit patiently while 
the reader seems not to be working. This protocol 
can be used alone, with “dumb” memory tokens or 
with processor-based tokens. 


1 Introduction 


Smart cards have been used in many applications 
that require that the data be secured from the card- 
holder. In the Modex stored-value smart card sys- 
tem, for example, the smart card stores a particular 
monetary value. An attacker who can successfully 
change the value stored in the card can essentially 
print money.!_ In GSM phones, smart cards pro- 
vide identity information used to prevent cloning 
and in billing. An attacker who can modify that 
information can charge cellular phone calls to an- 
other account [?]. Smart cards used to protect satel- 
lite television can be attacked to obtain free services 
[McC96]. 


These cards are vulnerable to a large class of at- 
tacks [And94, Sch97, Row97, Sch98], from reverse- 
engineering [AK96] and protocol failures [AN95] 
to side-channel attacks [Koc96, Koc98, KSWH98, 
DKL+99] and fault analysis [BDL97, BS97]. In all of 
these attacks, the attacker can defeat the security of 
the card by breaching its secure perimeter and learn- 
ing the confidential information stored within. With 
reverse-engineering, the attacker defeats the tamper- 
reisistance measures directly; with side-channel and 
fault-analysis attacks, the attacker exploits weak- 
nesses in the physical security to learn information 
within the secure perimeter. 


1For other examples, see [CP93], [SK97], and [RKM99]. 


There is another class of applications for smart 
cards—applications in which the value of a success- 
ful attack is much smaller. These cards might pro- 
vide micropayment information, low-security access 
control, or act as payment vehicles in circumstances 
with low marginal cost of goods (pay television, pub- 
lic transportation, etc). In these applications we are 
less concerned with individual fraud, and more con- 
cerned with an organized attack to create and dis- 
tribute fake cards. Someone who sneaks onto the 
subway or watches a satellite movie without paying 
isn’t going to affect the service provider’s bottom 
line, but someone who is able to counterfeit access 
tokens that allow everyone to sneak onto the subway 
or watch the movie could collapse the entire system. 
Hence, the primary threat is not from an isolated 
attack against a single card, but an attack that can 
be scaled to multiple cards. 


The threat is from untrusted card readers that the 
user may stick his card into. In this paper, we pro- 
pose a low-tech authentication protocol that is useful 
in this sort of situation. Our protocol makes use of 
what we will call a “slow memory device”: a device 
that responds to queries by revealing the contents of 
different memory locations, but one that necessarily 
takes several seconds to do so. 


The protocol relies on the fact that the cardholder 
does not have infinite patience. If he puts his smart 
card into a reader and nothing happens for several 
seconds, he will likely pull the card out and try 
again. If nothing happens again, he will find an- 
other reader. The slow response of the card ensures 
that a fraudulent reader can only do so much dam- 
age before the cardholder removes his card. 


This protocol makes no cryptographic assumptions, 
and is independent of any cryptography that may or 
may not be in the system. It can be implemented by 
itself, or in conjunction with cryptographic controls. 


The rest of the paper is organized as follows. In Sec- 
tion 2 we describe the slow memory device and its 
functionality. In Section 3, we describe our authen- 
tication protocol. In Section 4 we discuss variants 
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and extensions to this basic protocol, and in Section 
5 we discuss applications. 


2 The Slow Memory Device 


This protocol assumes the existence of a slow mem- 
ory token. By this we mean a token—a smart card, 
a Dallas Semiconductor iButton, etc.—that acts as 
a memory device, but never responds to a request in 
less than ¢ seconds (t = 10, for the purposes of this 
example). It is impossible for a terminal to get more 
information during that time; the token’s electronics 
are such that it simply cannot respond to requests 
faster. 


This memory token has m memory locations, each w 
bits wide (w = 64 for the purposes of this example). 
The token does not need a processor, nor does it 
need to implement any cryptographic primitives in 
order to execute this protocol. 


3. The Basic Protocol 


There are three parties in this protocol: 


e The Token: The slow memory device. 
e The Terminal: The untrusted card reader. 


e The Trusted Machine: A trusted computer 
connected to, and possibly remote from, the 
Terminal. 


Our authentication protocol is simple. A user inserts 
his Token into a Terminal. The Terminal now needs 
to prove to a Trusted Machine that the Token is 
currently inserted into the Terminal. 


The Terminal is only marginally trusted, and could 
be malicious. In order to complete the protocol cor- 
rectly the Terminal must be connected, via a secure 
data link, to a Trusted Device. The Trusted Device 
keeps an exact copy of the contents of the Token; 
this is a shared secret that the Terminal does not 
know. 


Our protocol is as follows: 
(1) The holder of the Token inserts it into the Ter- 


minal. 


(2) Terminal reads the header information from the 
Token. 


(3) Terminal sends this information over an en- 
crypted link to the Trusted Device. 

(4) Trusted Device generates a random challenge 

and sends it back over the encrypted link to the 

Terminal. This challenge consists of a list of n 

memory locations on the Token. 


(5) Terminal reads the n memory locations from 
the Token, XORs them all together, and sends 
the result back over the encrypted link to the 
Trusted Device. 


(6) The Trusted Device verifies this information; if 
it checks out, it believes that the Token is cur- 
rently inserted into the Terminal. 


Note that there are no cryptographic primitives in 
the protocol: the only mathematical operation in- 
volved is XOR. There are no encryption functions, 
one-way hash functions, or message authentication 
codes used in the protocol. 


The Token might have 1000 64-bit memory loca- 
tions. Each time read request comes in, it takes ten 
seconds to respond, and without reverse-engineering 
the device and tampering with its internals, this 
can’t be made any faster. Assuming ten seconds per 
communications exchange, and setting n = 1, steps 
(2) and (3) take ten seconds, step (4) takes another 
ten seconds, and step (5) takes another ten seconds. 
This gives us a total of 30 seconds per transaction. 
Now, this can be extended a little bit without the 
user knowing. A malicious Terminal might ignore 
the protocol completely, and simply query the Token 
(repeat step (5)). Maybe the Terminal can perform 
six queries instead of one, doubling the transaction 
time, before the Token owner removes his card. 


To provide adequate security, we need to account for 
possible malicious behavior by the Terminal in how 
many transactions are allowed, keeping the probabil- 
ity of success acceptably low even if most Terminals 
are corrupt. 


3.1 Reasonable Values for n 


Suppose the Token has m memory locations, that 
each instance of the protocol requests the XOR of 
n random locations, and that n << m. Assuming 
an attacker eavesdrops on each authentication, he 
will learn the contents of nm memory locations, not 
all of them different, after each transaction. The 
average number of authentications that the Token 
can accomplish before the attacker has a better than 
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0.5 chance of impersonating the Token (that is, being 
able to respond correctly to a random query), is: 


log(n)/(log(m) — log(m — n)) 


For example, for m = 1000 and n = 5, an attacker 
who eavesdrops on 322 authentications has a better 
than 0.5 probability of being able to impersonate the 
Token by answering a random challenge correctly. 


This, of course, is not the most effective attack. A 
fraudulent Terminal will specifically query the To- 
ken to learn the memory locations that it does not 
know. Hence, a malicious Terminal can learn the 
entire contents of a Token in m/n queries. So for 
the parameters above, a malicious terminal that con- 
ducts 100 fraudulant transactions will have a better 
than 0.5 probability of being able to impersonate 
the Token. The Token owner, though, would have 
to be convinced to allow the Token to be used in 100 
ineffectual transactions. 


4 Extensions 


4.1 A Button on the Token 


Ideally, we’d have some user-interface mechanism on 
the Token, like a pushbutton. The Token is willing to 
perform only once per button-push. Alternatively, 
the Token buzzes or lights up once per memory query 
answered. This would make multiple queries much 
harder for the Terminal to make, since the Token 
owner could detect that the protocol was not pro- 
ceeding as specified. 


4.2 Reducing Storage Requirements 
in the Trusted Device 


As written, the Trusted Device must store a com- 
plete copy of the Token’s memory location. If this 
is too much memory, the Trusted Device could store 
the Token’s ID information and a secret key known 
only to it (and not the token). The Token’s meme- 
ory locations would then be the memory address en- 
crypted with this secret key, and would have to be 
loaded onto the Token by the Trusted Device. 


4.3. CRC Hardware on the Token 


If the Token can afford CRC hardware, then queries 
can be handled using this alternate protocol: 
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(1) The holder of the Token inserts it into the Ter- 
minal. 


(2) Terminal reads the header information from the 
Token. 


(3) Terminal sends this information over an en- 
crypted link to the Trusted Device. 


(4) Trusted Device generates a random challenge 
and sends it back over the encrypted link to the 
Terminal. This challenge consists of a list of n 
memory locations on the Token. 


(5a) The Terminal sends the Token a request for the 
n memory locations. 


(5b) The Token goes through the motions (and de- 
lay) of sending it out internally, but only out- 
puts the 32-bit CRC of the n requested memory 
locations. 


(6) The Trusted Device verifies this information; if 
it checks out, it believes that the Token is cur- 
rently inserted into the Terminal. 


Each memory location can now be 32 bits long, and 
even one unknown memory location in the query 
string prevents an attacker from succeeding in an 
impersonation attack. Note that this system works 
best if there are lots of Terminals under different 
entities’ control. If a Token only interacts with one 
Terminal every time it executes the protocol, then 
this system doesn’t work very well. 


4.4 Incrementing Values in the Token 
and Trusted Device 


If we’re worried about an attacker reverse- 
engineering and making lots of copies of the Token, 
then we have each query of memory location cause 
that memory location to increment by one, mod- 
ulo 2°?, or rotate left one bit, or whatever else is 
cheap enough to be implemented. Note that this up- 
date must occur on both the Token and the Trusted 
Device, and assumes that there is either only one 
Trusted Device or that the different Trusted Devices 
can communicate with each other securely to syn- 
chromize these updates. 


This variant does not help against impersonation at- 
tacks. What it does do is to make continued synchro- 
nization of those counterfeit Tokens very expensive 
and complex. Now, if any memory location in the 
challenge string has been changed, the duplicated 
Token fails to give the correct answer. 
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4.5 Reducing the Amount of Trust in 
the Trusted Device 


A given Trusted Device may be only partially 
trusted. Instead of having it store a complete list- 
ing of the Token’s memory locations, it can be given 
a series of precomputed challenges in order and the 
right responses to be expected. (If we use the previ- 
ous extension, this will work only for small numbers 
of different Trusted Devices.) 


5 Security Analysis 


The slow memory protocol is designed to frustrate a 
particular kind of attack. It is intended to provide 
security against an insecure reader trying to collect 
enough information from a token to be able to im- 
personate it. It does not provide security against 
someone reverse-engineering the token and cloning 
it (although the extension described in Section 4.2 
considerably frustrates that attack in most circum- 
stances), nor does it provide security in the event 
that the back-end database (the Trusted Device in 
the protocol) is compromised. 


A more extensive security analysis will be in the final 
paper. 


6 Applications 


A complete discussion of applications, along with 
their security ramifications, will be in the final pa- 
per. 


The most obvious applications are things like non- 
duplicable keys for locks and alarms, free passes or 
one-day (or k-day) coins, and login keys. In these 
applications, we are less concerned with a single per- 
son hacking the authentication device than the same 
single person being able to distribute a large number 
of them. 


One of the most beneficial aspects of this protocol 
is that it works well with cryptography, even though 
it has no cryptography itself. We can use a message 
authentication code such as HMAC [BCK96] in ad- 
dition to this protocol, and if the MAC breaks, the 
memory trick still works. Or course, all Trusted De- 
vices must be trusted with copies of the memory 
maps. 


7 Conclusions 


Security countermeasures must be commensurate 
with the actual threats. In this paper we have pre- 
sented a low-tech security solution that helps miti- 
gate a specific threat, and can be used in conjunction 
with other cryptographic countermeasures. 
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Abstract 


Smartcard software developers suffer from the 
lack of a standard communication framework 
between a workstation and a smartcard. To 
address this problem, we extended the UNIX 
filesystem to provide access to smartcard stor- 
age, which enables us to use files in a smartcard 
as though normal UNIX files, but with the ad- 
ditional security properties inherent to smart- 
cards. 


1 Introduction 


Today, it is easy to purchase smartcards in rea- 
sonable prices, e.g., $5 - $20 for each. How- 
ever, smartcard software development is hard: 
smartcard software developers have long suf- 
fered from the lack of a user friendly stan- 
dard communication protocol between appli- 
cation software! and a smartcard. The ISO- 
7816 communication protocol [9] is so widely 
accepted that virtually all smartcards support 
it.2 However, the protocol is not a particularly 
desirable one: 


e It is a primitive message passing proto- 
col. Providing only read and write opera- 


1 “A pplication software” is a program running on a 
workstation that communicates with a smartcard. A 
programrunning on a smartcard is called “on-chip soft- 
ware”. 

2 Almost all smartcards support ISO-7816-1, -2, and 
-3; many also support ISO-7816-4 [18] 


tions for raw data, it does not define high- 
level interfaces such as UNIX files and I/O 
streams. This hampers our ability to build 
application software. 


e Although all smartcards support ISO- 
7816, details of implementation of the pro- 
tocol differs among vendors and types of 
smartcards. This requires software devel- 
opers to tailor their applications to specific 
smartcards. 


Differences among smartcards range from 
trivial ones, such as different opcodes, to 
essential ones, such as different authen- 
tication mechanisms, etc. For example, 
the CLA byte of application class® is 0x00 
in some smartcards (Giesecke & Devrient 
STARCOS Version 2.1), while it is OxcO in 
others (Schlumberger MultiF lex). 


To address the deficiencies of ISO-7816, many 
new standards have been proposed. Examples 
are: 


e General purpose standards: Open Card 
Framework (OCF) [2, 8] and PC/SC [3, 4]. 


e Special purpose standards: PKCS #11 
[12] for cryptography, EMV [5] and SET 
for electronic commerce [13]. 


e On-chip software standards: JavaCard [15] 
and MULTOS [16]. 


Although these standards provide abstractions 
at a higher level than ISO-7816-4, it remains a 


3See Guthery and Jurgensen [6] or ISO-7816 [9] for 
a description of of “CLA” and “application class.” 
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challenging task for developers to select a stan- 
dard, purchase all software and hardware re- 
quired, learn API and tools, and finally imple- 
ment software. Furthermore, those standards 
do not eliminate problems with interoperabil- 
ity — e.g., OCF limits the programming lan- 
guage to Java; PC/SC is used only with Win- 
dows ~ and create their own API dependencies, 
because software written for one standard does 
not run with another. We discuss these issues 
in Section 5.1. 


Our solution to this problem is to embrace a 
classic, sophisticated API — the UNIX filesys- 
tem ~— instead of inventing a new one. The 
UNIX filesystem API suits a smartcard well 
because a smartcard is a passive device used 
for secure storage: a smartcard stores data (se- 
crets), and responds to requests from a work- 
station to read or write the data. It does 
not initiate actions. This passivity is charac- 
teristic of storage devices such as hard disks. 
Cryptographic functions, such as get challenge, 
internal and external authenticate, verify key 
and PIN, are unique to smartcards. However, 
smartcards still act passively for these func- 
tions, and they are implemented with ioct1(). 


In UNIX operating systems that support 
vnodes (equivalently, Virtual Filesystem, or 
VFS) [11] [14], it is possible to write a virtual 
filesystem that communicates with a special 
hardware device, e.g., a smartcard, and mount 
it in the UNIX filesystem name space. The 
mounted hardware device then becomes iden- 
tical to any UNIX filesystem hierarchy from 
the perspective of a user or application soft- 
ware. For example, if a smartcard is mounted 
on /smartcard, it is possible to use UNIX com- 
mands such as 1s, cd, pwd, and cat, and system 
calls such as open, read, and write on files in 
the smartcard. 


We have implemented a smartcard filesystem 
(or SCFS) in the OpenBSD-2.4* kernel. With 
SCFS mounted, a user or an application can 
use files in a smartcard as she would normal 
UNIX files. 


*OpenBSD is a free, 4.4BSD-based operating sys- 
tem. http://www.openbsd. org 
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The remainder of this paper is organized as fol- 
lows. Section 2 describes our goals and the 
design of SCFS. Section 3 details implemen- 
tation of SCFS. (Readers not interested in im- 
plementation details may want to skip Section 
3.) Performance evaluation in Section 4 shows 
that the overhead of SCFS is small and does 
not substantially degrade the performance of 
smartcard software. We discuss SCFS with a 
comparison to other standards in Section 5. Fu- 
ture direction is described in Section 6 and con- 
cluding remarks are in Section 7. 


2 Design 


2.1 Design Goals 


Our goal is to provide a user friendly interface 
to access a smartcard. We define design goals 
as follows, although not all can be achieved, for 
reasons outlined in Section 2.2: 


e Files in a smartcard should be indistin- 
guishable from other UNIX files. 


e A smartcard can be accessed with any 
UNIX system call (e.g., creat, open, 
read, and write). 


e UNIX commands (e.g., 1s, cd, pwd, and 
cat) can be used to access files in a smart- 
card. 


e The smartcard VFS must be able to access 
any smartcard that supports ISO-7816. 


e The smartcard VFS should hide details 
about a smartcard to users. 


e Security of asmartcard must be preserved. 


e No smartcard files may be cached in the 
UNIX system because a smartcard is a 
more secure place to store data (see the 
end of Section 2.3). 
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2.2 Design Problems 


A huge obstacle to achieving our goals is the 
absence of a standard way to request metadata 
information about files in a smartcard. Some 
information essential for the UNIX filesystem 
is simply not present in a smartcard, e.g., 
file sizes, directory contents, and time stamps. 
Without such information, it is impossible to 
implement the complete functionality of the 
UNIX filesystem. For example, without direc- 
tory entries, it is impossible to implement 1s 


properly. 


We have two choices, with concomitant trade- 
offs: 


e Dictate an internal format on a smartcard 
to store information such as directory en- 
tries, length of a file, etc., in a file in a 
smartcard. This provides full functional- 
ity of UNIX filesystems. 


e Degrade functionality of SCFS. For exam- 
ple, no ls, no cat. 


We compromise between the two choices. We 
believe it is essential to be able to determine a 
smartcard’s directory structure through UNIX 
commands such as 1s, so SCFS requires di- 
rectory structure information to be stored in 
a smartcard. We also require a smartcard 
to store file lengths because they are neces- 
sary to implement the read and write system 
calls. Every directory (or DF in ISO-7816) in 
asmartcard has a file called 2e.69 (“.i”) con- 
taining the requisite metadata. 


2.3 Design 


Inspired by Arla [19], SCFS is implemented as a 
kernel module, xfs, that handles VFS requests, 
and a user daemon, scfsd, that communicates 
with an ISO-7816 smartcard. Figure 1 shows 
the overview of the design. 


When an application calls a VFS operation 
(e.g., read or write to a smartcard file), the 


ISO-7816 







Application 


UNIX 
Filesystem 
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User-level 


Kernel 
——* XFS | 


Figure 1: SCFS design 


kernel module upcalls scfsd to request service. 
Scfsd creates ISO-7816 APDUs,® sends them 
to asmartcard, gets returned data, and passes 
it to the kernel module. 


Separation between xfs and scfsd allows us to 
use an existing ISO-7816 library [17] for han- 
dling the ISO-7816 protocol and dealing with 
its complex timing requirements. Kernel code 
is minimized, making SCFS easy to debug and 
port. 


To absorb differences among smartcards, SCFS 
requires some knowledge of a smartcard before 
it is mounted, e.g., existence of special APDUs, 
opcodes used for APDUs, ATRs° they return, 
etc. The information is stored in a SCFS con- 
figuration file, /usr/scfs/etc/scfs.scdb by 
default. 


SCFS automatically identifies a smartcard type 
from its ATR. When a reset signal is sent to a 
smartcard, it responds with a 4 - 32 byte ATR, 
unique to each smartcard type. The SCFS con- 
figuration file has a database of known ATRs. 
If the ATR from the smartcard is listed in the 
configuration file, SCFS retrieves the entry for 
that type of smartcard. Details about the con- 
figuration file are described in Section 3.6. 


Unlike most UNIX filesystems, SCFS does not 
cache data read or written because caching 
might degrade the security of data resident in a 
smartcard. Data in the UNIX filesystem (typi- 
cally ahard disk) is not protected as securely as 


5An Application Protocol Deta Unit, or APDU, can 
be viewed as a framing protocol for messages passed 
from application software to a smartcard [9]. 

6 Answer To Reset. 
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in a smartcard and is not protoected at all from 
an adversary with administrative privileges. In 
addition, files in a hard disk are usually backed 
up on tape, which may fall into the hands of 
an adversary. 


3 Implementation 


3.1 Overview 


As described in Section 2.3, SCFS is separated 
into a kernel module (xfs) and a SCFS dae- 
mon (scfsd), detailed in Sections 3.2 and 3.3, 
respectively. Communication between xfs and 
scfsd is detailed in Section 3.4. _Implementa- 
tion of SCFS is based on Arla-0.6. Communica- 
tion between xfs and scfsd is derived directly 
from Arla. 


3.2 Kernel Module (xfs) 


The kernel module (xfs) implements a virtual 
filesystem, the ioctl system call, and commu- 
nication with scfsd. 


The virtual filesystem consists of several func- 
tions called by the kernel when a file in SCFS 
is accessed. For example, the core part of 
the read system call is implemented by the 
xfs_read() vnode operation in the xfs. 


We describe some important vfs operations, 
xfs_mount() and xfs_root(), and some im- 
portant vnode operations, 2.¢e., xfs.lookup(), 
xfsread(), xfs.write(), xfs_getattr(), 
and xfs_readdir(), in Section 3.5. 


Xfs is typically loaded into the kernel at boot 
time. When xfs needs to communicate with a 
smartcard, it performs the communication by 
upcalling scfsd. For example, xfs_read() in- 
vokes xfs_message_readsc() in scfsd. Xfs 
waits until it receives data from scfsd, and 
sends the data back to the application with the 
uiomove kernel function. 


110 USENIX Workshop on Smartcard Technology (Smartcard '99) 


3.3 SCFS daemon (scfsd) 


Scfsd performs operations requested by xfs. 
For requests that require smartcard access, 
scfsd translates the request to ISO-7816 AP- 
DUs. Figure 2 shows an example of message 
flow when an application requests to read 8 
data bytes from a smartcard. 


{00, a4, bO, 00, 08} 


data 


read(8 bytes) 








Application 


data msg_readsc 


Sg_installdata (data) 


data 


Figure 2: Reading 8 data bytes from a 
smartcard 


3.4 Communication between xfs 


and scfsd 


Xfs communicates with scfsd through RPC. 
When xfs needs access to a smartcard, it con- 
structs a request message, puts it into a mes- 
sage queue, and waits for scfsd to reply. Code 
for sending a request to read 8 bytes from a 
smartcard is as follows: 


struct xfs_message_readsc msg; 


msg.header.opcode = XFS_MSG_READSC; 

msg. buf = buf; 

msg.size = 8; 

msg.offset = 0; 

fidcpy (msg.fid, xnode->handle) ; 

xfs_message_rpc(fd, &msg.header, 
sizeof (msg)) ; 


After invoking xfs_message_rpc(), xfs sleeps 
until it receives the result of the request. Scfsd 
eventually receives data from a smartcard and 
sends it back to the kernel module. Here is an 
example of sending a reply message: 
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struct xfs_message_installdata msg; 


msg.header.opcode = XFS_MSG_INSTALLDATA ; 
memcpy (msg. buf, data); 

msg.size = size; 
xfs_send_message_wakeup(fd, error, msg); 


3.5 Important VFS/Vnode opera- 
tions 


In this section, we detail the implementation of 
some important VFS and vnode operations. 


VFS Operations: 


e Xfs_mount() mounts SCFS on a specified 
directory. It first sends a reset signal to the 
smartcard. When it receives ATR from the 
smartcard, it scans the configuration file to 
find a smartcard description that matches 
the ATR, reads the configuration informa- 
tion, initializes scfsd, initializes xfs, and 
creates the mount point. 


e Xfs_root() operation selects a root direc- 
tory (3£.00) in a smartcard and installs 
an XFS node and a vnode for a root node. 


Vnode operations: 


e Xfs_lookup() translates a path to an 8 
byte fid.” It checks if the requested path- 
name and its parent are both in the direc- 
tory structure. If they are, it constructs 
and returns the fid. Currently, a path 
length is restricted to four components be- 
cause a fid is 8 bytes long, big enough to 
hold four ISO-7816 components, which are 
two bytes each. We map these two bytes 
into their ASCII equivalents in the natural 
way. 


e Xfs.read() reads data from a (possibly 
PIN-protected) smartcard file, as follows. 


7A fid is a file identifier that is unique in SCFS, 
consisting of names of the file itself and its ances- 
tors. For example, a fid of a file 3f .00/77.77/77 .01 is 
OT OLE TEs E0028. 98; 


(1) It selects the target file. (2) When 
the current file and the target file have the 
same parent, the target file is selected by 
a select APDU. Otherwise, the entire path 
from the root must be navigated; ISO-7816 
does not allow selection ofan arbitrary file, 
only one in the currently selected direc- 
tory, so in this case, xfs_read() selects the 
root file (3£.00), and moves down a path 
one by one to the target file. (3) With the 
file now selected, xfs_read() sends a read 
APDU (e.g.,cO bO 00 00 length) to the 
smartcard. (4) If the read request fails be- 
cause the file is protected by a PIN, scfsd 
prompts the user for a PIN. The prompt 
is directed to the controlling tty of the ap- 
plication that issued the system call. (5) 
Finally, scfsd passes the data read back 
to the user via a call to the xfs layer and 
kernel uiomove(). 


e Xfs_write() behaves’ identically to 
xfsread(), except for the direction of 
data. 


e Xfs_getattr() installs a VFS attribute 
structure (struct vattr) and an XFS 
attribute structure (struct xfs_attr). 
Scfsd performs the actual construction of 
the XFS attribute structure and sends it 
to xfs, which converts it into a VFS at- 
tribute structure. 


e Xfs.readdir() is typically called by a 
getdirentries() system call, often as a 
result of an ls command. It returns di- 
rectory entries (struct dirent) of a se- 
lected directory. Each entry describes a 
file or a directory in the selected directory. 
ISO-7816 shortcomings require that we de- 
fine our own metadata strategy, described 
in Section 2.2. Xfs_readdir() constructs 
full directory entries from the directory en- 
tries and from our metadata file and re- 
turns them to the application. 


Some functionalities in a smartcard do not fit 
the concept of a filesystem. For example, there 
is no system call to read a PIN to authorize a 
user. However, these functionalities are neces- 
sary to take advantage of security features of 
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a smartcard. To incorporate them into SCFS, 
we use the ioct1() operation.® Ioct1() takes 
an opcode and data and performs an opcode- 
specific action. 


Implementation of ioct1() is straightforward, 
translating one opcode to one APDU. Ioct1() 
implements create file, verify PIN, verify a 
key, internal authentication, external authenti- 
cation, get response, and get challenge APDUs. 


3.6 Configuration File 


The configuration file (stored in 
/usr/scfs/lib/scfs.scdb by default) 
includes entries for ATR, the name of the 
smartcard, the CLA byte used for APDUs, 
whether the APDUs are supported by the 
smartcard, the type of supported PIN protec- 
tion, etc. An example of a configuration file is 
as follows: 


ATR 3b 32 15 0 49 10 { 
CARDNAME CyberFlex 
MULTIFLEXPIN no 
MULTIFLEXGETRES no 
CLA_DEFAULT c0 
CLA_VERIFYKEY £0 
CLA_READBINARY £0 
CLA_UPDATEBINARY £0 
CLA_READRECORD -1 
CLA_UPDATERECORD -1 

} 

ATR 3b 2 14 50 { 

CARDNAME MultiFlex 
MULTIFLEXPIN yes 
MULTIFLEXGETRES yes 
CLA_DEFAULT c0 
CLA_VERIFYKEY £0 

} 

ATR 3b 23 0 35 11 80 { 
CARDNAME PayFlex/MCard 
MULTIFLEXP IN no 
MULTIFLEXGETRES no 
CLA_DEFAULT 00 

} 


8 We use ioct1() to avoid adding a new system call; 
this decision will be revisited someday. 
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The byte string after the “ATR” tag is matched 
with the ATR returned from a smartcard at 
reset. The CLA_* tags defines CLA bytes for 
specific APDUs, used by scfsd to construct 
APDUs. -1 means that the APDU is not sup- 
ported in the smartcard type. If a CLA byte is 
not specified for the APDU, CLA_DEFAULT 
is used. For example, in CyberFlex, the CLA 
byte is Ox£0 for the verify_key, read_binary, and 
update_binary APDUs. Read-record and up- 
date_record APDUs are not defined. OxcO is 
used for the CLA byte for the other APDUs. 


4 Performance Evaluation 


Here we evaluate the performance of SCFS, im- 
plemented on two Schlumberger cards, Mul- 
tiFlex and CyberFlex Access. Our test har- 
ness is based on a 400 MHz Pentium running 
OpenBSD-2.4. 


4.1 Method 


We measured total elapsed time and smartcard 
access time for various vnode operations. The 
difference reflects filesystem overhead. Figure 
3 shows this relation. 


o—_o—_—_________—_-_-® 


read(2) start reading end reading read(2) 
call smartcard smartcard returns 
eww et we te ee ee ee ee ee ee ee ee ee ee ee ee > 
Total Time 
GA it gO nt gg ene 0 ym 0 aa ss > 
smartcard access time 
==> ewe eee . 


scfs overhead scfs overhead 


Figure 3: Performance Evaluation 


Serial communication with smartcards uses 12 
bits per byte (one start, eight data, one parity, 
two stop bits). Our test harness communicates 
with MultiFlex at 38.488 Kbps, or 312 psec. 
per byte, and with CyberFlex Access at 55.928 
Kbps, or 215 psec. per byte. 
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4.2 Result 


To measure read and write performance, we 
used six different operand sizes, ranging from 
1 byte to 254 bytes. Figure 4 shows the result. 
For both cards, elapsed time as a function of 
operand size is very close to linear. 





L& 
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Cyberflex Access nae aoe 
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Cyberflex nese, Wh 
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Figure 4: read/write time 


Table 1 shows the card-related per-byte cost 
for these functions. Most of the overhead, evi- 
dent by the non-zero y-intercept, is due to (un- 
known) card processing time; operating system 
overhead is under 1 ms in each case. Some 
of the per-byte card processing time is evident 
in the difference between the theoretical mini- 
mum read cost and the measured cost. Write 
times are substantially longer than the theo- 
retical minimum, reflecting the time required 
to write to EEPROM. 







Card | Op | Per-byte | 
MF 


read 0.257 
write 5.62 


Table 1: Read and write performance. All 
times in ms. 
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4.3 Breakdown 


Table 2 shows the cost of some other operations 
for the CyberFlex Access card. 


[op [Card 
Sa 
Pek [0 


Table 2: Read and write performance. Times 
in ms. Bytes represent the amount of data 
transfered in the operation. 
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The directory structure cache, created at 
mount time by reading the “.i” file, is evident 
in the open and lseek operations, which do not 
communicate with the card. Verify key, not a 
vnode operation, is implemented with pioctl. 


5 Discussion 


5.1 Related Work 


Here we discuss three important related works, 
OCF, PC/SC, and some special purpose stan- 
dards. 


OCF 


OpenCard Framework is middleware that sup- 
ports a smartcard with Java [2, 8] by provid- 
ing high-level APIs, vendor transparency, card 
type transparency, and extensibility. These ob- 
Jectives are similar to ours. The principal ad- 
vantage of OCF is that it employs Java. Pro- 
grammers familiar with Java can start smart- 
card programming easily. The following is an 
example taken from “OpenCard Framework 1.1 
Programmer’s Guide” [7]. It reads a file “id” 
(0x6964) and prints it out to standard output. 
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public static void main(String[] args) 
{ 
System. out. println( 
“reading smartcard file..."); 


try { 
SmartCard.start(); 


// wait for a smartcard with file 
// access support 
CardRequest cr = 
new CardRequest ( 
FileAccessCardService.class) ; 
SmartCard sc = 
SmartCard. waitForCard(cr) ; 


FileAccessCardService facs = 
(FileAccessCardService) 
sc. getCardService( 


FileAccessCardService.class, true); 
CardFile root = new CardFile(facs); 


CardFile file = 
new CardFile(root, ":6964"); 


byte[] data = 
facs.read(file.getPath(), 0, 
file. getLength() ); 
sc.close(); 


String entry = new String(data) ; 
entry = entry.trim(); 
System.out.println(entry); 


} catch (Exception e) { 
e.printStackTrace(System. err) ; 


} finally { // even in case of an error 


try { 
SmartCard. shutdown(); 

} catch (Exception e) { 
e.printStackTrace(System. err) ; 


ue 
e 


System. exit (0) ; 


The example code is easy to understand for 
those familiar with Java. Programmers can 
take advantage of the higher abstraction of 


Java, such as I/O streams, etc. OCF is inte- 
grated with JavaCards, providing a consistent 
development environment for application soft~ 
ware and on-chip software. 


However, the reliance on Java can also be 
viewed as a disadvantage. Java and its object 
oriented model modularize and simplify com- 
plex software, but a smartcard is a simple, pas- 
sive device. For many smartcard applications, 
Java might be viewed as overkill. 


In SCFS, we use a smartcard in a simple way. 
For example, we can print out a file (as in the 
OCF example) by typing: 


¥% mount_scfs /dev/scfsO /smartcard 
% cat /smartcard/id 


OCF cannot be used with languages such as C 
and C++, the languages in which most oper- 
ating systems and security protocols are writ- 
ten. Consequently, OCF offers little to en- 
hance directly the security of many operating 


systems and security protocols, such as UNIX, 
Kerberos, SSH, and PGP. 


PC/SC 


PC/SC is a general purpose architecture for in- 
tegrating a smartcard into PCs [3]. Its objec- 
tives are similar to OCF and SCFS. According 
to part 6 of the specification [4], the PC/SC 
API is similar to the UNIX filesystem, featur- 
ing Open(), Close(), Read(), Write(), Seek(), 
etc. Therefore, usability of PC/SC and SCFS 
are similar. 


Unlike OCF, PC/SC supports multiple lan- 
guages and development environments, such 
as C, VC++, VB+-+, and Java. However, 
it is used only with Windows operating sys- 
tems. While SCFS currently supports only 
OpenBSD, it is possible to port it to other 
UNIX systems, and (perhaps) even to Windows 
NEY 


°Tf we purchase the Installable Filesystem package. 
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Special Purpose Standards 


Application specific standards such as 
PKCS#11, EMV, and SET have advan- 
tages in usability in specific domains because 
of higher abstractions than SCFS. In SCFS, 
functionality to take advantage of smartcard 
security, such as internal and external au- 
thentication, is given by the ioct1l() system 
call. However, ioct1() is not as user friendly 
as the functionality provided by PKCS#11, 
EMV, and so on. We may provide libraries for 
specific purposes to wrap around SCFS to give 
higher abstractions. 


5.2 Advantage of SCFS 


Transparent API with the UNIX Filesys- 
tem 


SCFS differs from the other approaches such as 
OCF and PC/SC because it is implemented as 
an operating system extension. Consequently, 
to an application, smartcard files look identical 
to files stored on other media. With SCFS, an 
application can use a smartcard without mod- 
ification (Figure 5). 


Application Application 
—— 


Figure 5: Application is not modified to 
use SCFS. 


With SCFS, many UNIX applications can take 
advantage of smartcard security without mod- 
ification. For example, here is how we made 
SSH work with a private key stored in a 
smartcard: we added a symbolic link from 
$HOME/.ssh/identity to /smartcard/ss/id 
and copied a private-key to the SSH identity 
file. 


citi mount_scfs /dev/scfsO /smartcard 

citi% ln -s /smartcard/ss/id 
“/.ssh/identity 

citi ssh sin.citi.umich.edu 


Enter PIN: 
sin% logout 


PGP works with a private key in a smartcard 
in a similar way: 


citi mv ~/.pgp/secring.pgp 
/smartcard/pg/ky 
citiZ% in -s /smartcard/pg/ky 


“/.pgp/secring.pgp 


Although not tested yet, Kerberos tickets and 
browser cookies can be stored in SCFS in sim- 
ilar ways. 


In contrast, OCF or PC/SC require that an 
application be modified to use a smartcard be- 
cause the API for asmartcard is different from 
the API for normal files (Figure 6). 


Application 


Application i 


Figure 6: Application must be modified 
to use OCF or PC/SC 


OCF or PE€/SC 





Portability 


Another advantage of SCFS is portability. 
Most of the SCFS code is in user space and 
easily ported to other operating systems. The 
xfs kernel module is based on Arla, which is 
already ported to many UNIX-like operating 
systems, including Solaris, NetBSD, FreeBSD, 
OpenBSD, Linux, AIX, HP-UX and Digital 
UNIX. It is easy to port SCFS xfs to other 
operating systems. 


5.3 SCFS as Development Tool 


Smartcard standards other than SCFS give 
higher abstractions for users, e.g. Java lan- 
guage in OCF, EMV’96 for electric commerce, 
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PKCS#11 for cryptographic applications, etc. 
Depending on the type of applications, dif- 
ferent kinds of abstraction may be required. 
Therefore, there are many standards that do 
not interoperate [1]. In contrast, SCFS works 
with a raw smartcard with a minimum amount 
of abstraction; no matter what functionality 
a smartcard offers, SCFS can access and use 
its secure storage. SCFS allows users to ac- 
cess a smartcard with sophisticated UNIX com- 
mands, such as cd, 1s, pwd, cat, etc. SCFS is 
especially helpful in maintenance, testing, and 
debugging; Figure 7 depicts our model of SCFS 
as a development tool. 


Application Development 








Application 





OCF PC/SC] EMV PKCS#11 


Maintenance, Test, Debug 





Figure 7: SCFS as a low-level develop- 
ment tool. 


6 Future Directions 


Some ideas derived from other smartcard 
standards suggest enhancements to SCFS. In 
PC/SC, asmartcard specific driver is loaded as 
a DLL (Dynamic Loadable Library). In SCFS, 
smartcard specific code is directly written in 
the user-level daemon, scfsd. PC/SC’s ap- 
proach is more extensible than ours because it 
does not require recompilation to add a driver 
for a new smartcard. We are considering ex- 
tending SCFS to have the same advantage with 
dynamically loadable libraries. 


We intend to port SCFS to different operating 
systems and to support more smartcard types. 


(Currently it supports only Schlumberger Mul- 
tiFlex, CyberFlex, and PayFlex). 


Security of SCFS should be explored. SCFS is 
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currently vulnerable to Trojan Horse attacks, 
a.e., if an adversary has administrative privi- 
leges, she can install a rogue version of SCFS 
that steals a user’s PIN or modifies contents of 
the smartcard. We are investigating integrity 
checking and authentication of SCFS code by 
a smartcard. 


We plan to use SCFS in several applications. 
One of them, storing Kerberos tickets, is par- 
ticularly interesting, as it dovetails with our 
related Kerberos V5 smartcard extensions [10]. 
In that application, the smartcard performs de- 
cryption on Kerberos tickets. Storing the result 
in a protected SCFS file indicates the synergy 
of our approach. 


7 Conclusion 


We have implemented a Smartcard Filesystem 
(SCFS) to ease development of smartcard soft- 
ware. SCFS provides a UNIX filesystem API 
for a smartcard. Developers can use the well- 
established UNIX API and development envi- 
ronment to develop smartcard software. Per- 
formance evaluation shows the overhead caused 
by SCFS is negligible. 
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Abstract 


Since the invention of the Java Card, the issue of code 
and data sharing has beena topic of great interest. Early 
Java Cards shared data via files secured with access 
control lists. Java Card 2.1] specification introduced a 
method of object sharing, allowing access to methods of 
server applets using Shareable Interface Objects (SIO). 


However, this SIO approach can be improved. It permits 
access to all interfaces of the SIO, whereas some inter- 
faces may be intended only for particular clients. AID 
impersonation could be used to gain access to services 
unless the card authenticates all applets. Access to a 
SIO by future applets may be impossible. Passing object 
data between applets is quite cumbersome. 


An approach to object sharing based on delegates is de- 
scribed, which provides needed improvements with min- 
imal modifications to Java Card 2.1. Using the delegate 
approach, only the desired methods of an applet are ex- 
posed, and each method can be protected by any security 
policy the applet wishes to implement. A shared secret 
security policy is described, using challenge/response 
Phrases to avoid revealing the shared secret. Sucha se- 
curity policy does not require applet authentication to 
avoid AID impersonation, and lends itself readily to ac- 
cess by any future applets that may be written. 


1 Introduction 


Since the invention of the Java Card, the issue of 
code and data sharing has been a topic of considerable 
interest. The first Java Cards [2] shared data between 
Java Card applets using a file system secured by access 
control lists. These lists determined which identities 
could access particular files, and what permission each 
identity was granted with respect to each file. The iden- 
tities were established using key files and PIN verifica- 
tion. This solution was quite powerful for many com- 
mon data sharing situations; however it did not lend it- 
self well to situations requiring access to methods 
belonging to another Java Card applet. 
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Figure 1: Basic Java Card Architecture 


A typical Java Card architecture is shown in Figure 
1. The card contains an operating system, Java Card Vir- 
tual Machine [7], Java Card Runtime Environment 
(JCRE), and the Java Card API in ROM. Applications 
are Java packages programmed to the API, and are usu- 
ally loaded into EEPROM. An application consists of 
one or more applets; applets in different packages are 
separated by a firewall to prevent access to applet data 
across package boundaries. Applets are programmed 
using a subset of Java, and have a specified set of entry 
points that trigger various actions on the card [6]. 

In this paper, we will describe the object sharing 
mechanism introduced in Java Card 2.1, examine the is- 
sues associated with this mechanism, and propose alter- 
natives that address these issues. We rely heavily on 
code examples, key elements of which are inserted into 
the paper at relevant points. Sometimes the code in the 
paper is edited for brevity, and comments containing 
“..” indicates the removal of code not pertinent to the 
discussion. The complete Java source code for these ex- 
amples can be found in http:/Awww.cyberflex.slb.com/ 
usenixMK99.html. Note that when discussing the dele- 
gate examples, this code uses a framework which is suit- 
able for simulation on a workstation, and is not intended 
for use on a Java card. 
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2 Object Sharing In Java Card 2.1 


The Java Card 2.1 specification [10] introduces a 
means of sharing objects between Java Card applets. Al- 
though somewhat more difficult to use than file sharing, 
it does provide a means for accessing object methods, 
rather than just data. This specification uses a unique ap- 
plet identifier (AID) [4] as the basis for determining 
which applets are granted access to objects created by 
other applets. 


2.1 Description Of Object Sharing Mechanism 


The strict firewall enforcement of Java Card 2.1 
completely prevents an applet from accessing data cor- 
responding to another applet. However, a provision was 
made for an applet to obtain an interface belonging to 
another applet, and to invoke a method on this interface. 
This forms the basis of the Java Card 2.1 object sharing 
mechanism. 


2.1.1 Restricting Method Access through a SIO 


Normally in Java [1], it would be possible to access 
public methods across packages. Therefore, one could 
use public methods in other packages without a need for 
a sharing mechanism. 

But this poses a problem for Java card, because the 
applet entry points are necessarily public, yet we must 
restrict access to them to prevent applets from running 
other applet methods without permission. So the JCRE 


does not permit any method to be invoked in other ap- 
plets, except through the SIO mechanism. This prevents 
obvious hacks, such as casting an object reference to 
gain access to all of the public object methods, bypass- 
ing the restriction of the interface. 


2.1.2 Applet Context 


The object system in a Java Card is partitioned into 
separate protected object spaces referred to as contexts. 
All applets in a given package share the same context, 
and are prohibited from accessing objects in a different 
context due to firewalls which are enforced by the Java 
Card Runtime Environment (JCRE) [8]. The JCRE is 
able to access objects in any context, and global arrays 
such as the APDU buffer (which are owned by the 
JCRE) can be accessed by applets in any context. 


2.1.3 Shareable Interface Objects (SIO) 


Shareable interfaces are a new feature in the Java 
Card 2.1 API [9] to enable applets to explicitly share ob- 
jects by defining a set of shared interface methods. Such 
shareable objects are called Shareable Interface Objects 
(SIO). We can think of those applets which provide SIO 
as server applets (since they will provide access to their 
services via the SIO), and those applets which use the 
SIO of another applet as client applets. Note that an ap- 
plet may be a server to some applets, and yet a client of 
other applets. 


register() 


Step 1: Server registers itself 


ICS ystem.petAppletShareablelnterfuceQb ject ServerAl D,byte) getShareablelnterfaceObject(ClientA/D,byte) 





Step 3: Client has ‘transparent’ access only to the server SIO 


Figure 2: Creating and accessing a SIO 
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2.1.4 Creating a SIO 


In order to create a new SIO, a server applet A must 
first define a shareable interface X, which extends the 
interface javacard.framework.Shareable. Applet A then 
defines a class C that implements the shareable interface 
X, and creates an instance O of class C. Object O is now 
a SIO. An instance of applet A with an AID is registered 
with the JCRE, as shown in Figure 2, step 1; this AID is 
subsequently used by client applications to specify the 
server applet. 


2.1.5 Obtaining a SIO 


A client applet must obtain this SIO in order to ac- 
cess object O. The process of a client obtaining an SIO 
is shown in Figure 2, step 2. 

In order for client applet B to access object O, applet 
B must create an object reference BO of type X, and 
then call a system method getAppletShareableInter- 
faceObject with the AID of the server, and an optional 
byte which selects which interface is desired (for those 
servers with more than one interface available). The 
JCRE looks up the server applet associated with that 
AID, and forwards the request to the server, replacing 
the first argument with the client AID. Server applet A 
receives the request and the AID of the requester (applet 
B), and determines whether or not it will share object O 
with applet B. If applet A finds the request agreeable, 
then a reference to O is provided; otherwise, null is re- 
turned. The JCRE forwards this reference to Applet B. 
Applet B receives this reference (which is of type SIO), 
casts it to type X, and stores it in BO. 


2.1.6 Using a SIO 


Once a SIO has been obtained, applet B can invoke 
any methods from interface X on object reference BO, 
which then accesses object O. However, this is not as 
straightforward as it might seem, due to the firewalls. 

Figure 2, step 3 shows the client applet B on the left, 
and the server applet A on the right, with a firewall in 
between. Note that the only part of applet A that is visi- 
ble through the firewall is object O. When applet B in- 
vokes a method on BO, a context switch is triggered in 
the JCRE, leading to the situation in Figure 3. At this 
point, applet B is not visible at all; the only data visible 
from B are the arguments passed on the stack (and the 
global APDU array). 

Note than it is pointless to pass object references on 
the stack, since the firewall will prevent object O (in Ap- 
plet A) from using them, due to the context switch. 


However, object O can access any allowed data in Ap- 
plet A as shown in Figure 3. 


Server 


Applet 
A 





Figure 3: Server has no access to client data 
2.2 Object Sharing Issues 


There are four issues of concern with object sharing 
in Java Card 2.1. 


2.2.1 Access To All Interface Methods Of A Class 


The JCRE protection mechanisms do not prevent in- 
terfaces from being maliciously cast into other kinds of 
interfaces that might exist for a given object. 

Once granted any interface, it is possible to access 
all of the shareable interface methods of an object via an 
explicit cast (not just the interface granted to a particular 
client). So if my server applet has two interfaces, intend- 
ed for different kinds of clients, a client who legitimate- 
ly obtains one interface, could cast it into the other inter- 
face, and gain access to unintended methods. 

For example, suppose an applet ABCLoyaltyApplet 
has two different services that it intends to offer exclu- 
sively to two different clients, ic. grantFequentFlyer- 
Points for client Airline, and grantLoyaltyPoints for cli- 
ent Purse. Both of these services are accessible to re- 
spective clients via different published interfaces, but 
both are defined in the Applet class, as illustrated in 
Code 1. 


package AppABC; 
import javacard. framework.*; 


public interface ABCLoyaltyAirlineInterface extends Shareable ( 
public void grantFrequentFlyerPoints(int amount) ; 
} 


public interface ABCLoyaltyPurseInterface extends Shareable {( 
public void grantLoyaltyPoints(int amount) ; 
} 


public class ABCLoyaltyApplet extends 
javacard. framework.Applet implements 
ABCLoyaltyAirlineInterface, ABCLoyaltyPurseInterface { 


Protected int loyaltyPoints; 
Protected int frequentFlyerPoints; 


/* A service only for client ‘Airline’ */ 

public void grantFrequentFlyerPoints(int amount) {¢ 
frequentFlyerPoints += amount; 

} 


/* A service only for client ‘Purse’ */ 

public void grantLoyaltyPoints(int amount) { 
loyaltyPoints += amount; 

} 


public ABCLoyaltyApplet() throws Exception ( 


USENIX Workshop on Smartcard Technology (Smartcard '99) 


121 


loyaltyPoints = 0; 
frequentFlyerPoints = 0; 
/* Add code to initialize potential client AIDs ... */ 
register (); 
) 
public void process() { 
/* Various code specific to services for this applet, 


such as point redemption code ... */ 
) 


public Shareable getShareableInterfaceObject ( 
AID clientAID, byte parameter) { 

if (clientAID. equals (purseAppletAID) ) 

return (ABCLoyaltyPurseInterface) this; 
else if (clientAID.equals(airlineAppletAID) ) 

return (ABCLoyaltyAirlineInterface) this; 
else 

return null; 


) 


Code 1: Server defines and grants access to SIO 


If the Purse client was aware of the Airline client in- 
terface, it could make use of the interface it had been 
granted by the server applet to grant loyalty points, and 
instead use the grantFrequentFlyerPoints interface (in- 
tended for client Airline) to maliciously add unwarrant- 
ed frequent flier points, as shown in Code 2. 


package AppPurse; 


import javacard.framework.*; 
import AppABC.*; 


public class PurseApplet extends javacard.framework.Applet ( 


private int value; 
private ABCLoyaltyPurseInterface abcSI0O; 


public PurseApplet() throws Exception { 
value = 0; 
abcSIO = (ABCLoyaltyPurseInterface) 
JgCcSystem.getAppletSharableiInterfaceObject ( 
abcLoyaltyAppletAID, (byte)0); 
register(); 
) 


public void use(int amount) ( 
value -= amount; 
if (abeSIo != null) 
abcSIO.grantLoyaltyPoints (amount) ; 


/* Attempt to ‘hack’ by using an SIO to access the Airline 
* applet's exclusive service grantFrequentFlyerPoints */ 
ABCLoyaltyAirlineInterface hackSIO = 
(ABCLoyaltyAirlineInterface) 
JcSystem.getAppletSharableInterfaceObject ( 
ABCLoyaltyAppletAID, (byte)0); 
if (hackSIO != null) 
hackSIO.grantFrequentFlyerPoints (amount) ; 
} 
/* Other methods follow for adding points to the purse ... */ 
) 


Code 2: Client compromises SIO 


Unfortunately, the JCRE is unable to prevent such 
access, since it does not violate the restriction of access 
only via shareable interfaces. 

This problem can be eliminated by using separate 
delegate objects for each shared interface, and have the 
delegate objects handle or redirect the calls to the in- 
tended object. Another solution is to verify the AID of 
the caller upon each attempt to access a method in the 
server. 

Furthermore, it is not possible to grant a client ac- 
cess to only certain methods of an interface. If such 


granularity is required, further delegates and interfaces 
must be used to separate the particular methods that are 
to be allowed for each applet. Alternatively, this granu- 
larity can be provided by having each method individu- 
ally check the client AID, to determine whether the cli- 
ent should have access to that particular method. 


2.2.2 AID Impersonation 


The decision by a server applet to grant access to an 
object must be based solely on the AID of the requesting 
applet; no other information is available to the server ap- 
plet. The intended use is clearly to allow certain inter- 
faces to be granted only to particular client applets, as 
denoted by their unique AIDs. However, it is possible to 
maliciously set the AID of a rogue applet to be the same 
as the AID of a client applet known to have access to a 
particular interface. The rogue applet is then loaded in- 
stead of the applet that legitimately owns the AID. Once 
loaded, the rogue applet can request the desired inter- 
face. The server applet, having only the AID for refer- 
ence, will naturally grant this request, since the AID 
matches the required AID for the interface. The rogue 
applet can then freely use the interface for malicious 
purposes. 

This is a critical security problem. Current solutions 
to this problem require restrictions on applet loading, 
such as only allowing applets to be loaded that are 
signed by trusted sources. However, this approach 
greatly reduces the flexibility of Java Cards; for exam- 
ple, this prevents users from loading Java Card pro- 
grams of their own devising. 


2.2.3 Future Reference To Shared Objects 


Granting access by AID necessarily assumes that the 
server applet that wishes to share the object has fore- 
knowledge of all AIDs of all client applets that are to be 
loaded which will share particular interfaces. This is a 
difficult requirement for any kind of server. But what 
about other client applets that are written afterwards 
which legitimately need access to the shared object? 
Such applets are excluded from access to the object, 
since the server can only grant access based on the AID 
list that the server had when it was loaded. This necessi- 
tates rewriting and reissuing the server applet such that 
the new AIDs are included, which may pose an insur- 
mountable hurdle when the server applet is already 
widely distributed. 


2.2.4 Inability To Pass Object Parameters 


The inability to pass object parameters between ap- 
plets can make many tasks cumbersome. For example, 
supposes as a client needs to pass an object when invok- 
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ing a method on a server applet so that the server can 
manipulate and return the object, as in encrypting a 
buffer. In this case, the object might contain a field spec- 
ifying the method of encryption, a key array, and a data 
array. But as stated earlier, the firewall prevents the 
server applet from accessing this data, even if an object 
reference from the client is provided. 

One might envision a work around to this problem 
where the server A gets a shared interface on an object 
in client B in order to read the object data as shown in 
Figure 4. 





Figure 4: Server access blocked by firewall 


However, this will fail, since any attempt by server 
A to get the object data from client B will also be 
blocked by the firewall. The server can only invoke 
methods on the client object, but the client object has no 
means for returning the object data, other than a single 
field at a time. Thus the only current work around to this 
problem is to use the global APDU buffer to pass data 
as shown in Figure 5. 


Seen global APDU Buffer 





Figure 5: Data exchange via global APDU buffer 


This is awkward at best, since the data being passed 
may not be of appropriate length or type to be readily 
passed viathis mechanism. Consequently, the client and 
server might have to make multiple calls and consider- 
able manipulations to pass the desired parameters, due 
to the restrictions of the APDU buffer. 

This problem could be addressed by changing the 
firewall restrictions to permit access to shared objects 
(including data), instead of just interfaces; however, this 
could potentially create security holes. Applets must 
coded carefully to avoid exposing methods and data that 
are not intended to be shared. But if instead of actually 
sharing the applet object, the applet used a delegate to 
expose only the desired methods and data, the JCRE 


specification could be altered to permit access to only 
delegate methods and data, thus eliminating the object 
parameter problem, with a minimum of security risk. 


3 Delegate Approach To Object Sharing 


Based on an analysis of these critical problems, an 
approach to object sharing was devised which avoids 
these drawbacks. In this approach, each server applet 
that wishes to permit access to its methods or data cre- 
ates a single delegate, which is registered with the sys- 
tem based on the AID of the applet. The delegate ex- 
poses only those methods and data that the applet wishes 
to share. Access to the delegate is public; all methods in 
the delegate can be accessed by any other applet! 

Since access to the delegate is unrestricted, an applet 
protects itself in two ways. First, the delegate is written 
to only access the desired methods of the server applet; 
other applet methods cannot be accessed. Second, the 
methods of the delegate can perform any checks as 
deemed necessary to check the validity of the access to 
the delegate; if the checks are not passed, the delegate 
can refuse to pass the request on to the applet. 


3.1 Java Card 2.1 System Changes Required 


This approach presumes the addition of two new 
Java Card 2.1 system methods. A version of register is 
needed which takes a delegate and AID as arguments. A 
system method getDelegate returns the delegate associ- 
ated with a particular AID. These methods replace the 
JCSystem.getAppletShareableInterfaceObject and 
Applet.getShareableInterfaceObject methods. Further- 
more, the JCRE is altered to permit access to methods 
and data of delegate objects (DOs) in other contexts 
(just as it now permits access to methods of SIOs in dif- 
ferent contexts). 

For performance reasons, it would be worthwhile to 
investigate whether it is necessary for the JCRE to re- 
strict access to objects in other contexts at all, since 
checking object context imposes a speed penalty. Tech- 
niques such as the delegate method proposed, coupled 
with classical Java language and runtime protec- 
tions[11,5], could perhaps result in a better performing 
system that still meets the security requirements. 


3.2 Delegate Server Implementation 


A server applet must be written containing the de- 
sired methods. For this example, we show a loyalty 
server applet in Code 3 from the ABC company that al- 
lows granting, using, and reading loyalty points. 
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package AppABC; 
import OSResources.*; 


public class ABCLoyaltyApplet extends OSResources.Applet [( 
private String aid = "AppABC.ABCLoyaltyApplet"; 
private int loyalty; 


public ABCLoyaltyApplet() { 

loyalty = 0; 

register(new ABCLoyaltyDelegate(this), aid); 
) 


void grantPoints(int amount) ( 
loyalty += amount; 


} 


boolean usePoints(int amount) ( 
if (loyalty >= amount) { 
loyalty -= amount; 
return true; 
} else ( 
return false; 
) 
) 


int readPoints() { 
return loyalty; 
} 
) 


private ABCLoyaltyApplet myApplet; 

private ChallengePhrase cp; 

private ChallengePhrase checkcp; 

private byte grantTriesRemaining = FAILURES_ALLOWED; 
private byte useTriesRemaining = FAILURES_ALLOWED; 


protected ABCLoyaltyDelegate(ABCLoyaltyApplet a) [( 
myApplet = aj; 
cp = new ChallengePhrase (CHALLENGE_LENGTH) ; 
checkcp = new ChallengePhrase(CHALLENGE_LENGTH) ; 
} 


public boolean grantPoints(int amount) { 
// do some checking 
iff (myApplet != null) ( 
ABCLoyaltyInterface pD = (ABCLoyaltyInterface) 
OSystem.getDelegate( 
OSystem.getPreviousContextAID()); 
if (pD != null) { 
/* Create new random challenge phrase */ 
checkcp.setPhrase(cp.randomize()); 
/* Get’ client response to phrase */ 
byte[] response = pD.loyaltyChallenge (cp) ; 
byte[] xr = checkcp.encrypt (secret1) ; 
if (isEqual(response,r)) ( 
/* See if client gave the correct response */ 
grantTriesRemaining = FAILURES_ALLOWED; 
myApplet.grantPoints (amount) ; 


return true; 
} else ( 
if (--grantTriesRemaining == 0) myApplet = null; 
return false; 


Code 3: Server applet registering its delegate 


Note that the only novel aspect of this applet is when ) 
it creates and registers its delegate, as illustrated in Fig- o's 
ure 6, step 1. Whenever a server applet wishes to allow return false; 
access to another applet, a delegate must be written , 
which exposes the desired methods. Such a delegate is 


public boolean usePoints(int amount) ( 
/* Access to this method uses secret2, for different 


shown in Code As clients, but is otherwise similiar to grantPoints ... "/ 
, 
package AppABC ; public int readPoints() ( 
import OSResources.*; if (myApplet != null) 
i return myApplet.readPoints(); 
public class ABCLoyaltyDelegate extends Delegate { else 
‘ : return 0; 
final static byte CHALLENGE_LENGTH = (byte) 64; } 
final static byte FAILURES_ALLOWED = (byte) 2; ) : 
private byte[] secretl = { /* initializing code ...*/ ); 


Code 4: Server delegate 


private byte[] secret2 = { /* initializing code ..,"/ }; 


register(Delegate,ServerAlD) Server 
Applet 


Step 1: Server registers it’s delegate 


JCSysten.geiDelegate(ServerAlD, byte) 


Client 
Applet |. 


DO (or null) @ JCRE 


Step 2: Client obtains access to server delegate from JCRE 


ecess to DO 
methods and data 


Client 
Applet 


Step 3: Client has ‘transparent’ access only to the server delegate 





Figure 6: Creating and accessing a delegate 
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This delegate is registered with the AID of the server 
applet at the time the applet is instantiated on the Java 
Card. At this point, this delegate is publicly accessible 
by any other applet. This particular delegate defines the 
interface ABCLoyaltyInterface shown in Code 5, which 
must be implemented by client applications. The rea- 
sons for this interface are discussed in detail in Section 
3:3: 


package AppABC; 
import OSResources.*; 


public interface ABCLoyaltyInterface( 
public byte[} loyaltyChallenge(ChallengePhrase cp); 
} 


Code 5: Server defines interface that each client 
must provide to handle challenge/response 


3.3 Delegate Security 


A delegate controls which methods each client can 
access. This delegate exposes three methods: grant- 
Points, usePoints, and readPoints. The method read- 
Points has no validation, and may be freely used by any 
client. 

But what about the methods that require proof that 
the access is valid, such as grantPoints and usePoints? 
These methods could just check the AID of the client. 
This effectively mimics the object sharing of Java Card 
2.1, which is subject to the risks of AID impersonation 
and difficulty of adding future clients. 

These problems can be avoided by using the ctassi- 
cal solution of shared secrets. In this example, access to 
grantPoints is controlled by secret] ; only clients that can 
authenticate knowledge of secret] will have their re- 
quest passed from the delegate to the server applet. Ac- 
cess to usePoints is controlled by secret2, which allows 
a potentially different set of clients to access this meth- 
od. 

There are many standard techniques for handling 
shared secrets and other methods of authentication [3]. 
We are not proposing anything new here, other than the 
application of these techniques to this problem, to avoid 
the limitations and pitfalls of security based on AID. 
The details of the application of the shared secret tech- 
nique to Java Card is presented in detail for the benefit 
of those who may not be familiar with such techniques, 
or may be unclear how they can be implemented in a 
Java card. 

Proving knowledge of the secret could be a tricky 
proposition. Passing the secret as an argument to the 
server applet is a bad idea, since the secret could be in- 
tercepted in a number of ways. (One simple way to get 
the secret is to write a applet that impersonates the serv- 
er applet, thus capturing the secret when it is passed as 
an argument.) A superior approach is to use challenge/ 


response phrases, as illustrated by the server delegate in 
Code 4. When access is requested, the server delegate 
sends arandom challenge phrase to a predefined method 
in the client delegate. This challenge phrase is encrypted 
using the secret by the client delegate, and returned to 
the server delegate. The server delegate performs the 
same encryption, and if the results match, access is 
granted. Thus the secret is never revealed outside of ei- 
ther applet. 


3.4 Delegate Client Implementation 


When a client applet wishes to use the server applet, 
it calls getDelegate with the AID of the server applet, 
and receives a delegate, which it casts to the proper del- 
egate class associated with the server applet, as shown 
in Figure 6, step 2. The client applet then invokes meth- 
ods on the delegate as desired. Note that unlike SIO, the 
JCRE hands out the delegate, and server applet is not in- 
volved. The client in Code 6 was written assuming au- 
thentication using challenge/response. 


package AppPurse; 


import OSResources.*; 
import AppABC.*; 


public class PurseApplet extends OSResources.Applet ({ 


public String aid = “AppPurse.PurseApplet"; 
private byte[] secretl = ( /* initializing code .,.*/ ); 
private int value; 


public PurseApplet() { 

value = 0; 

register(new PurseDelegate(this), aid); 
) 


public byte[] loyaltyChallenge(ChallengePhrase cp) ( 
return cp.encrypt(secretl) ; 
) 


public void use(int amount) { 
value -= amount; 


ABCLoyaltyDelegate d = 
(ABCLoyaltyDelegate) 
OSystem.getDelegate("AppABC .ABCLoyaltyApplet"); 

if (d != null) ( 
d.grantPoints (amount) ; 

) 

} 
/* Other methods follow for adding points to the purse ... */ 


) 
Code 6: Client applet invoking server method 


To handle the challenge/response, the client must 
supply a delegate as shown in Code 7 that the server will 
call to perform the necessary encryption with the chal- 
lenge phrase. This client delegate must implement the 
ABCLoyaltyInterface, as defined by the server applet. 
The delegate may not actually perform the encryption, 
but may instead pass the challenge/response request to 
the client applet for processing. This allows the dele- 
gate to avoid holding the shared secret, reducing the se- 
curity risk. 
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package AppPurse; 


import OSResources.*; 
import AppABC.*; 


public class PurseDelegate extends Delegate implements 
ABCLoyaltyInterface{ 


private PurseApplet myApplet; 


protected PurseDelegate(PurseApplet a) ( 
myApplet = a; 
} 


public byte[] loyaltyChallenge(ChallengePhrase cp) [ 
if (myApplet != null) 
return(myApplet, loyaltyChallenge (cp) ); 
else 
return null; 


) 


Code7: Client challenge/response delegate 
3.5 Overview Of Client/Server Communication 


At this point, it is presumed that the server has al- 
ready registered with the JCRE, and that the client has 
already obtained the server delegate, as shown in Figure 
6, and the client is ready to use a service from the server. 
The resulting client/server communication using a 
shared secret is illustrated in Figure 7. 

The client begins by requesting a service from the 
server. This is done by invoking a method on the server 
delegate object ©. The method in the server delegate 
determines what level of protection is required; in this 
case, it determines that a shared secret must be validated 
to use this method. It therefore requests the delegate for 
the client from the JCRE @, which the JCRE provides 
(if it exists) ®. Assuming the client delegate was suc- 
cessfully obtained, the server obtains a random chal- 


response[Challenge] @® 


lenge phrase, and sends it to the client delegate @ using 
the interface the server had predefined for this purpose. 
The client delegate passes the challenge to the client ap- 
plet (which contains the secret) ©. The client applet en- 
crypts the challenge phrase using the shared secret, and 
returns the response phrase to the client delegate ©. 
The client delegate then passes the response phrase to 
the server delegate @. The server delegate also en- 
crypts the challenge phrase with the shared secret, and if 
the results match, the secret is validated. The server del- 
egate then forwards the service request to the server ap- 
plet ®, which processes the request, and returns a re- 
sponse to the delegate @, which is forwarded to the cli- 
ent applet @. 

If the nature of the server applet is such that the ser- 
vices are likely to be reused by a given client in a single 
session, then after validation of the shared secret, the 
server would likely be designed to return a session key 
(which permits access only during the current session, 
which ends when power is cycled). The client could 
then access that particular service through the delegate 
by providing the session key, thus avoiding the over- 
head of validating the shared secret for each access of a 
delegate method. Although the session key is provided 
by the client to the server in clear text form, there is no 
real security risk, since the server randomizes the cur- 
rently active session key each time power is cycled. So 
even if the session key were intercepted by an applet im- 
personating the server, it could not be used to breach se- 
curity, due to the randomizing of the session keys. 











Client Delegate 
issueChallenge() 






issueChallenge() © 


response{Challenge]} 
Client Applet , 


response[Service] 


requestService() 


| Server Delegate 


® 
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O 
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requestService() 


@ 
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Figure 7: Challenge/Response validation of shared secret 
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4 Conclusion 


The proposed delegate method of object sharing im- 
proves on the SIO approach. It protects each method as 
desired, so that no client applet gains access to unintend- 
ed methods of a server applet. It avoids AID imperson- 
ation, since AIDs can be supplemented with shared se- 
crets or other authentication mechanisms. It avoids fu- 
ture reference problems, since access need not be linked 
to any particular AID, but can simply be based on a 
shared secret which can easily be added to future client 
applications. Moreover, it requires only a minimal ad- 
dition to the Java Card system. Since the delegate meth- 
od allows each applet to determine the security policy 
desired on a per method basis, this allows the maximum 
flexibility for granularity of access by each individual 
client. 
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Abstract 


Java Card promises the ease of programming in Java 
to the world of smart cards. Java’s memory model how- 
ever is resource intensive especially for smart card 
hardware. Hence, adapting Java’s memory model to 
Java Card must retain the easy programming para- 
digm while enabling Java Card applications to maxi- 
mize the use of smart card memory. To this end, the 
Java Card 2.1 Specification [3] advocates an ad hoc 
persistent memory model that foists an unnatural pro- 
gramming paradigm and an inherently limited API. 

In this paper we discuss memory model choices for 
Java Card in the context of persistent systems. We pro- 
pose the concept of a transient and persistent environ- 
ment for encapsulating the transient and persistent ob- 
jects in Java Card applications. While offering a sim- 
ple programming model, it allows efficient sharing of 
the memory resources among multiple applications 
and enables garbage collection for Java Card. 


1 Introduction 


The Java [1] environment possesses a number of 
features that make it’s adoption to smart cards attrac- 
tive. A reasonable subset of the Java environment can 
constitute the base for a multifunction smart card plat- 
form. Applications can rely on standardized APIs and 
may be compiled into an intermediate bytecode repre- 
sentation enabling execution by a Java virtual machine. 
The simplicity and wide acceptance of the Java pro- 
gramming language is attractive to the smart card com- 
munity where no standard language suitable for devel- 
oping multifunction smart card applications has yet 
been established. Finally, they can benefit from the 
platform independence and security features provided 
by the Java environment. 

However, Java’s platform independence places sig- 
nificant constraints on the specific target platform. Java 
provides automatic memory management and does not 
foresee any means of manual memory control. In par- 
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ticular, it does not provide explicit support for persis- 
tent objects. In contrast, a smart card application re- 
quires random access to both transient and persistent 
memory. The limited amount of the memory resources 
available and their physical characteristics require sim- 
ple and transparent manipulation of objects in both 
types of memory by the application. Hence, one of the 
challenges in the design of the Java Card is adapting Ja- 
va’s memory model to the constraints of smart card 
hardware. 

Systems that require an intimate composition of 
long-lived data and programs are called persistent ap- 
plication systems [6]. Since applications in a Java Card 
are coupled with data, it enables the card to be a persis- 
tent application system. Orthogonal persistent systems 
[6] specially provide an appealing programming model 
for application development. Current smart card hard- 
ware typically offers around 16K bytes of persistent 
memory and nearly 1K bytes of transient memory. Giv- 
en such constraints a Java Card cannot provide the 
same degree of transparency and orthogonality as an 
orthogonal persistent system. While it may not be de- 
sirable to completely hide the lifetimes of objects in the 
Java Card, it could be done in tandem with handing 
some control to the programmer. The necessary restric- 
tions must be carefully chosen to provide a high degree 
of programmer convenience while enabling a reason- 
able utilization of the resources available in a smart 
card. 

In this paper, we present the choices underlying dif- 
ferent Java Card memory models. In particular, the dif- 
ferences, advantages, and drawbacks of each are high- 
lighted. The notion of the transient and persistent envi- 
ronment is introducedas a solution toward simplifying 
Java programming on smart cards, data sharing, and 
support for efficient garbage collection. 

The paper is organized as follows. Section 2 de- 
scribes the typical memory layout in smart cards and 
introduces the basic execution model of applications in 
a Java Card. Section 3 lists the different lifetimes of ob- 
jects which result from the given execution model and 
presents plausible allocation and placement strategies. 
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Section 4 discusses concepts underlying persistent sys- 
tems in general and their applicability to smart cards. 
Section 5 outlines the approaches to introduce tran- 
sience and persistence in the Java Card which were dis- 
cussed during the Java Card specification process. Sec- 
tion 6 introduces the basic concepts and usage of tran- 
sient and persistent environments. Section 7 discusses 
the implications of the transient environment on securi- 
ty, memory reclaiming and object sharing contrasting it 
with the approach taken by the Java Card 2.1 Specifica- 
tion. Finally, we present our conclusions in Section 8. 


2 Smart Card Memory and Java Card 
Basics 


Current and upcoming smart card hardware provide 
very limited storage capabilities. The memory resources 
typically consist of Read Only Memory (ROM), Ran- 
dom Access Memory (RAM) and Electrically Erasable 
Programmable Read Only Memory (EEPROM). EE- 
PROM is used to store long-lived data. In contrast, 
RAM loses its contents after a power loss and is thus 
only available for temporary storage. Both EEPROM 
and RAM can be read and written; however, write oper- 
ations to EEPROM are typically thirty times slower than 
to RAM and the possible number of EEPROM writes 
over the lifetime of a card is physically limited. Another 
difference lies in the physical size of each of these mem- 
ory types. The physical size constraints on a smart card 
dictate RAM/EEPROM ratios often resulting in consid- 
erably smaller RAM in comparison to EEPROM. 

A typical Java Card design places the operating sys- 
tem, the virtual machine and one or more applications in 
ROM. EEPROM is used to store applications which 
have been loaded after a card has been issued. Java Card 
applications, also referred to as applets, correspond to 
Java packages and are not loaded as regular Java class 
files [2]. Instead, a converter coalesces all the class files 
that comprise the package into a compactrepresentation 
with minimal symbolic information. The converted 
code is linked on the card against the system classes and 
other required packages. It is up to the converter and the 
virtual machine to assure the Java language protection 
rules for downloaded code. 

Once downloaded the applet is installed in a separate 
step. The virtual machine calls the mandatory install 
method which allocates required resources and registers 
a persistent object, the applet instance, with the Java 
Card runtime environment for future invocations. Ap- 
plet execution is tailored around the server centric na- 
ture of a smart card and takes place during sessions. 
When a card is placed in a card acceptance device 
(CAD) the runtime is initialized and awaits input. Com- 
munication is handled by the underlying operating sys- 


tem. An external application (the client) initiates a ses- 
sion with a specific applet (the server) by sending a se- 
lect command to it. The runtime marks the selected 
applet active and forwards the command by invoking 
the applet’s select method. Each command sent by the 
client hence is forwarded and handled by invoking the 
applet’s process method. The applet processes the com- 
mand and prepares a response which is sent after the ap- 
plet has returned from its invocation. A session ends 
when a new select command is received. The runtime 
deselects the currently selected applet by invoking its 
deselect method and initiates a session with the newly 
selected applet. 

During a session, an applet can access both the ser- 
vices of linked packages and services exported by other 
applets. A client applet can ask a server applet for a ser- 
vice by obtaining a reference to a shared object and in- 
voke it freely during the session. When invoked, the 
server object can check the identity of the caller and 
grant the requested service. Note that the Java stack is 
completely unwound upon cessation of communication 
with the CAD. 


3 Object Lifetimes 


The object allocation, placement and invocation 
model influences the lifetime of objects in the system. 
Object lifetimes in persistent systems fall into one of the 
following general categories [4]: 


1. Transient (temporary) results in expression evalua- 
tions and local variables in procedure activation. 
Data in this category resides in the individual byte- 
code frames and is of a primitive type. Java and 
Java Card do not allow the explicit allocation of 
objects on the stack which is especially limited on 
the Java Card. The stack contents must only be 
valid during applet invocation in a session. 


2. Instance variables, class variables and heap items 
whose extent is different from their scope. 
Among these items are especially objects which 
must be accessible during applet invocation or the 
entire session. They must not be saved in case of 
power loss. For example, objects of this type are 
used to store the state of the communication, ses- 
sion keys or the communication buffer. 


3. Data that exists between two program executions. 
Objects in this category cover data which must be 
stored in EEPROM to survive a power loss. 


4. Data that exists between different versions of a pro- 
gram or data that outlives the program. 
The Java Card environment currently does not 
address this category. 
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The object lifetime categories and the memory types 
in smart cards give rise to the three following allocation 
strategies for objects in a Java Card: 


1. Objects are instantiated in RAM and are serialized 
by the applet into EEPROM via a file system etc. 
This strategy resembles the regular Java environ- 
ment and of early Java Cards [11]. The applet 
instantiates objects in RAM and stores their data 
with the help of specific API functions into the 
long-term store. Each applet has to implement the 
functionality required for serializing and deserializ- 
ing its state. There are two drawbacks with this 
approach. First, the working set of an applet could 
be larger than the available RAM. Second, the 
underlying operating system must manage the con- 
tents of the long-term store, 1.e., it must provide a 
name binding with the serialized state and a means 
of checking the access rights of applets. 


2. Object instantiation is always in EEPROM. 
If objects are instantiated in EEPROM the language 
protection rules can be used to verify the integrity 
of the system.This provides an uniform access to all 
the objects of an applet. This strategy is attractive 
since most data manipulations are performed on 
long-lived data. However performing all allocations 
in EEPROM may never be feasible since writes to 
EEPROM are extremely expensive and it’s life lim- 
ited. 

3. Object instantiation is in RAM and EEPROM. 
The instantiation of objects with limited lifetime in 
RAM saves space in EEPROM, increases the per- 
formance and adds additional security in case of 
sensitive objects like session keys which must get 
lost in case of power loss. Long-lived data is placed 
appropriately in EEPROM. The utilization of both 
stores for object allocation and manipulation should 
still aim at the benefits of object instantiations only 
in EEPROM, 1.e., allowing uniform access to 
objects and relying on Java’s language protection 
rules. 


4 Persistent Systems 


The Java environment is designed as a transient pro- 
gramming environment. The Java Card environment 
however must support access to both transient and per- 
sistent objects within Java language expressions. Persis- 
tent programming languages and environments strive to 
enable such manipulations transparently [5]. Language 
expressions manipulating persistent data are made to 
appear similar to expressions operating on data with 
shorter lifetimes. Other than transparency, persistent 


systems provide different degrees of data type orthogo- 
nality. Full orthogonality expresses the demand that any 
instance can be persistent regardless of its type and that 
its lifetime may not be expressed at instantiation time 
[6]. In any case, the lifetime of data must be easily ex- 
pressible by the programmer and persistent data must be 
identifiable as such by a simple and consistent mecha- 
nism. The principles of transparency, orthogonality and 
identification serve as the basis for persistent systems. 

Orthogonal persistent systems offer the highest de- 
gree of transparency and orthogonality and were hence 
chosen as the basic architecture for adding persistence 
to Java in the PJama project [7]. PJama allows any in- 
stance to be persistent regardless of its type and any ob- 
ject is identified as being persistent by verifying reach- 
abilty from a persistent root set. Persistent objects are al- 
ways manipulated in RAM and are lazily stabilized into 
the long-term store. 


5 Proposed Approaches 


In a Java Card objects allocated in RAM must be im- 
mediately copied into EEPROM when assigned to a per- 
sistent reference. Otherwise, unexpected power losses 
will lead to illegal references and loss of data integrity. 
Since the working set of the applet can exceed the avail- 
able RAM it can only be used as a cache. However, the 
extremely limited resources on a smart card make it im- 
possible to determine a suitable caching scheme which 
delivers sufficient results without assistance from the 
programmer. It is worth noting that even large orthogo- 
nal systems tend to be inefficient [10]. 

To counter inefficiency and provide control to the 
programmer, some persistent systems limit the extent of 
one or more principles of orthogonal persistent systems, 
i.e., they may restrict transparency or orthogonality [5]. 
The programming style is affected as little as possible. 
This is crucial for the Java Card which touts the simple 
and popular programming style of Java. Hence changes 
to the language to support persistence are prohibited. In- 
troducing lifetime aware bytecode instructions to the 
virtual machine must be avoided as they would hinder 
upgrading to another memory model. 


5.1 Transient Types 


A common approach to introducing persistency in 
statically typed languages is to make persistency depen- 
dent on type. Persistent objects must be instances of 
classes inheriting from a specific superclass or must im- 
plement a specific interface. One proposal advocated a 
Persistence interface causing implementing class in- 
stances to be allocated in EEPROM, all other class in- 
stances would reside in RAM. Alternatively, another 
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approach proposed a Local interface to mark class in- 
stances to be allocated in RAM, with unmarked instanc- 
es allocated in EEPROM. 

There are two problems with this approach. Firstly, 
references to transient objects in the persistent set lead 
to dangling pointers in case of sudden power losses. 
Since an applet acquires access to its state by its persis- 
tent instance at invocation time, it is required to store a 
transient reference in its persistent set as soon as it uses 
a transient object. Resetting dangling pointers at the be- 
ginning of a card session involves complex scanning 
and is time consuming due the writes required to EE- 
PROM. Secondly, it requires having two type hierar- 
chies for classes whose instances may be transient or 
persistent. This especially restricts the use of array ob- 
jects which can either be persistent or transient but never 
both. Additional classes simulating the behavior of 
fixed built-in types maybe required as well. The result- 
ing code bloat and the performance penalty incurred by 
wrapper classes makes this approach unacceptable for 
smart cards. 


5.2 Transient Fields 


The introduction of separate type hierarchies may be 
avoided by using or extending particular language fea- 
tures [8][9]. Changes to the language are forbidden in 
Java as it affects programming style, requires educating 
programmers and forces changes to the Java compiler. 
Java however provides a transient keyword, a field 
modifier that affects object serialization. Fields marked 
transient are not part of the persistent state of the encap- 
sulating object and are not serialized. It seems natural to 
reuse the transient modifier in Java Card to mark fields 
whose data must reside in transient memory and must 
never be saved in the persistent image of the object. The 
advantage of this approach is that the persistent set is 
only connected with the transient object set at the loca- 
tion of the transient fields. This allows for simpler and 
efficient implementations for resetting the persistent set. 

The main drawback of using transient fields is it’s 
inability to express transience in a consistent manner. 
The value of a reference type transient field is the refer- 
ence itself. Since the transient keyword does not indi- 
cate the lifetime of the referenced object it’s meaning 
must be extended to include the transience of the refer- 
enced object. The extended definition fails to specify the 
lifetime of an object which is referenced by a transient 
and a persistent field as well. Changes to Java semantics 
also prevents future introduction of the transient key- 
word with uniform semantics in Java Card. 


5.3 Transient Data (Java Card 2.1 
Specification) 


Since the main requirement is to disable storing sen- 
sitive and data requiring fast access to long-term store a 
memory model may allocate data associated with cer- 
tain objects in short-term store. The current Java Card 
2.1 Specification follows this approach and is based on 
two basic design decisions. Firstly, applets must be de- 
signed to not expect any form of memory reclamation 
on the card. Applets are required to instantiate needed 
data at installation time and reuse it throughout their 
lifetime. Unreferenced data cannot be expected to be re- 
claimed and therefore new allocations may fail. The sec- 
ond design decision is to avoid dangling pointers in case 
of sudden power loss by expecting all objects to be ref- 
erenced persistently via EEPROM. Only the data of ar- 
rays of primitive types can be allocated in RAM. As the 
new bytecodes allocate objects in the persistent store 
special static factory methods makeTransient Boolea- 
nArray, makeTransientByteArray, and makeTransient- 
ShortArray are used for allocating only the object head- 
er in EEPROM and the data in RAM. 


RAM 
EEPROM 







CLEAR ON 
RESET 
data 


CLEAR ON 
DESELECT 
data 


Transient headers 
© CLEAR ON RESET 
© CLEAR ON DESELECT 


Fig. 1: RAM usage between Applets 


Although the data part of such objects in transient 
memory is lost at power loss, the location and size infor- 
mation in the persistent header reserves its space over 
multiple card sessions. However, as RAM is shared by 
all available applets on the card it must be possible to 
limit the reservation of the transient data to less than a 
whole card session. Otherwise the entire RAM may be 
reserved after the installation of a few applets allocating 
transient data. The factory methods therefore take an ad- 
ditional argument, the duration identifier which either 
allows instantiations of arrays with ‘‘clear on reset’’ or 
“*clear on deselect’’ duration. Arrays with the ‘‘clear on 
reset’’ duration will keep their values during the whole 
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card session, i.e., their contents are not reset between 
multiple applet selections during a card session. The 
value of arrays with the ‘‘clear on deselect’’ duration are 
always cleared before their owning applet is selected. 
This coarse grained lifetime specification allows over- 
lapping the ‘‘clear on deselect’? RAM space across dif- 
ferent applets. Figure | shows an organization of the 
transient memory using this overlap. RAM is split into 
two segments, the ‘‘clear on reset’’ and ‘‘clear on dese- 
lect’? spaces which grow in opposite directions. Each 
newly allocated “clear on reset” array gets allocated 
from the globally reserved “clear on reset” space while 
each newly allocated “clear on deselect” array gets allo- 
cated at the beginning of the per applet “clear on dese- 
lect” space. The runtime must ensure that these two 
spaces do not overlap. 

A consequence of this design is that the entire ‘‘clear 
on deselect’’ space must be cleared at once before a new 
applet is selected. If a package contains more than one 
applet the ‘‘clear on deselect’’ space has to be shared by 
all applets as they are allowed to share their transient ar- 
rays as per the Java Card 2.1 Specification. On the other 
hand, an applet shall allocate all its needed data, espe- 
cially its worst case usage of transient data, at install 
time. This can easily lead to the situation where the first 
applet ina package, having access to a sufficient amount 
of memory, will install successfully whereas the instal- 
lation of a cooperating applet in the same package may 
fail. The problem is compounded as the runtime is un- 
able to verify the usage of two very important memory 
resources pertaining to the applet, the required stack 
space and the worst case usage of the transaction buffer. 
These resources cannot be pre-calculated as they de- 
pend on the card specific bytecode frames, implementa- 
tion of the required packages, and the implementation of 
the transaction mechanism in case of the transaction 
buffer. This leads to a programming model where the 
programmer is forced to allocate some memory resourc- 
es in advance but still needs to check for their unavail- 
ability at runtime. 

The lack of transient objects and the restriction on 
transient arrays especially effects the convenient Java 
programming model. A programmer is forced to load 
and store values from persistent objects into transient ar- 
rays and vice versa. Additionally, since resources are 
limited and differ from card to card, programmers have 
to code to a least common dominator and cannot rely on 
the flexible use of transient data. Not only will this force 
programmers to use entirely persistent objects, the larg- 
er RAM capacities of upcoming smart card hardware 
will ironically remain unused. The different handling of 
transient and persistent data also causes different tran- 
sient and persistent object layout due to the indirect ac- 
cess to transient data through a persistent header. 


6 Transient Environment 


Monk: Why would anyone hurry to create gardens and buildings and 
monuments? 
Lord Buddha: Everything is transient and nothing endures. 


The problem of persistent and transient objects in 
Java Card can be stated as follows: How can the persis- 
tent object model of Java Card be augmented to enable 
flexible use of transient objects? The solution surpris- 
ingly lies in introducing a mechanism that is symmetri- 
cal to the persistent environment. The persistent envi- 
ronment consists of a persistent root, the applet instance 
and a set of objects reachable therefrom allocated in EE- 
PROM. Analogously, the transient environment is 
formed by a tree of objects with the difference that all 
objects reside in RAM. 

Both environments are separated in as far as refer- 
ences to transient objects are forbidden to be held in the 
persistent set. Storing references to transient objects in 
the persistent store is prevented by the virtual machine 
(VM) which throws an exception when such assign- 
ments are attempted. The Java (Card) bytecode instruc- 
tion set uses different instructions to store primitive and 
reference types; only the latter must be checked by the 
VM, making the overhead negligible compared to the 
necessary EEPROM write operation in case of a store. 
Assignments of persistent references in transient stores 
need not be checked as it does not affiect the integrity of 
the persistent store. Dangling pointers in case of power 
losses are avoided as transient references are never 
stored in the persistent set. 


public class DummyApplet extends Applet { 
public boolean select() { 
JCSystem.beginTransience() ; 

Object o = new Object (); 
JCSystem.endTransience(); 
JCSystem.setTransientEnvironment (0) ; 
return true; 


} 


public void short process(APDU apdu) { 
Object o; 
o = JCSystem.getTransientEnvironment () ; 
// use o 


Fig. 2: Using Transient Environments 


The lifetime of an object is controlled with the help 
of an API mechanism that demarcates transient alloca- 
tion defaulting to persistent allocation when not called. 
As shown in Figure 2 the API is used to toggle the allo- 
cation mode. Allocations between beginTransience and 
endTransience are in RAM, defaulting to EEPROM. 
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RAM overflow is signaled by an exception similar to 
how EEPROM overflow is signalled. This mechanism 
resembles atypical transaction API wherein behavior of 
state manipulation is toggled between a beginTransac- 
tion and commitTransaction code section. 

Allocated transient objects may be interconnected to 
form a transient environment whose root can be regis- 
tered with the Java Card runtime by invoking the set- 
TransientEnvironment method. Where a particular per- 
sistent environment is implicitly made available to the 
applet during invocation of the process method, the ap- 
plet can request its transient environment by explicitly 
invoking the getTransient Environment method. This al- 
lows accessing transient objects even when assignments 
of transient object references to persistent fields are pro- 
hibited. 

The transient environment naturally fits in the cur- 
rent execution model of Java Card applets. It may typi- 
cally be built in the beginning of a session in the select 
method. Transient data which must survive the session 
is copied to the persistent store at the end of the session. 
After the session, the transient environment is reset and 
the designated RAM space is available for the next ap- 
plet session. The ease of creating transient objects of 
any type leads to a convenient programming style, re- 
sults in better performance and more compact code. The 
similarities between the transient and persistent envi- 
ronment also simplifies virtual machine implementa- 
tions where the same object layout may be used for both 
the transient and persistent objects. 


7 Implications 


Apart from enabling a convenient programming 
mechanism the transient environment scales into the fu- 
ture when more smart card resources become available. 
The only limitation introduced by the transient environ- 
ment is the restriction on assignment. Future systems 
may choose to remove this restriction and still provide 
binary compatibility. The restricted assignment also en- 
hances security in that an applet cannot store a reference 
to a transient object which it received from the system 
or from a different applet in its persistent set. Since the 
object is only accessible during a session it cannot be ac- 
cessed in situations not foreseen by the service provider. 
For instance, it allows the deletion of a server applet 
without the danger of dangling pointers in the client ap- 
plet. The transient data approach is not upgradable in 
large part due to the fixed lifetimes in the API. The tran- 
sient space is statically split for the individual applets 
which make temporary allocations and deallocation in 
the future practically impossible. Lifetimes contradict 
the ease-of-use of standard Java. 
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The transient environment also strengthens other as- 
pects of the Java Card runtime, especially memory rec- 
lamation and the sharing mechanism. 


7.1 Memory Reclamation 


While not addressed by the Java Card 2.1 Specifica- 
tion memory reclamation can be very effective for the 
smart card environment. Clearly manual memory recla- 
mation cannot be allowed due to the security implica- 
tions and must be avoided in favor of garbage collec- 
tion. Surprisingly, EEPROM write performance and not 
the size of a general garbage collector is a hindering fac- 
tor with regards to a memory reclamation scheme. For 
instance, a simple mark and sweep garbage collector 
first annotates all reached objects and frees all unrefer- 
enced objects in a second pass [12]. It is most likely due 
to the limited RAM size that the annotation information, 
i.e. the mark bits, must be written into EEPROM. The 
resulting performance penalties make it impossible to 
interrupt the applet execution for garbage collection as 
soon aS memory is scarce but only at fixed points in 
time. However, cleaning up EEPROM is not as critical 
as that of RAM. 


7.1.1 Transient Environment Garbage Collection 


Typical applets allocate their persistent set at instal- 
lation time and limit the changes therein to data update. 
New instantiations or complete replacement may be 
considered rare. The RAM space is limited and can be 
consumed quickly as soon as an applet allocates tran- 
sient objects which are not reused in the transient envi- 
ronment but allocated only for the duration of an applet 
invocation. However, in case of transient environments 
garbage collection is not only feasible but indeed prac- 
tical. The transient environment can be garbage collect- 
ed completely separately from the persistent environ- 
ment. Persistent objects need not be scanned as their 
fields never reference transient objects. Our implemen- 
tation achieves satisfying results when invoking the gar- 
bage collector upon return from the applet’s select, de- 
select, or process methods. The Java stack is empty and 
the root set for the garbage collection consists only of 
the transient environment. 

The same garbage collector may be used for clean- 
ing up the EEPROM. Due to the limited performance 
this should only be carried out after an explicit request 
by an applet or by a special command from an external 
application. 
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7.1.2 Limitations of Transient Data Memory 
Reclamation 


EEPROM garbage collection is also permitted by 
the transient data approach. However, a different mech- 
anism must be used for reclaiming RAM space. The 
runtime can attempt to reuse the space for globally allo- 
cated ‘‘clear on reset’’ arrays after their applets have 
been deleted. It may also allow the increase of ‘‘clearon 
reset’’ space after the applet with the most “clear on de- 
select’? usage has been deleted. The added complexity 
stands in contrast to the low amount of memory which 
can be reclaimed generally in this static environment. 


7.2 Sharing 


The flexibility of the transient environment is not 
only afforded by the selected applet but also by the ser- 
vices it uses. The Java Card environment distinguishes 
and supports three different sharing scenarios: 


1. An applet is linked against a separate package. 
The package contains shared code used by different 
applets to create instances of classes and invoke 
methods in this package. 


2. An applet has a reference to a shared object pro- 
vided by a another applet. 
The client applet requests the reference from the 
runtime which forwards the request to the serving 
applet and returms the received reference to the cli- 
ent applet. The reference must be an interface type 
and the virtual machine will refuse any other 
attempts to access the methods specified by the 
inter face. 


3. An external application collaborates with two or 
more applets on the card. 

The applets know about the collaboration and want 

to keep access to their transient state as long as the 

collaboration lasts. 

The transient environment can provide a flexible use 
of transient data in all three scenarios. The degree of 
flexibility depends on the runtime providing support for 
only one transient environment, multiple transient envi- 
ronments and/or garbage collection. 


7.2.1 Single Transient Environment 


The transient environmentplays well in the first sce- 
nario wherein a shared package can either be given ac- 
cess to the transient environment of its client applet or 
can build its own transient environment. In the first case, 
the applet and package transient environment must obey 
Java type rules which involves the applet subclassing its 
environmentroot class to the package environment root 


class. In the second case, where the transient environ- 
ment of the applet and the package differ, the applet can 
use a simple mechanism to adopt its transient environ- 
ment to contain the package’s transient environment. 
The applet has to reserve one node in its environment 
for the root of the package environment. The first time 
it calls into the shared package it saves its current envi- 
ronment in a local variable and resets its environment at 
the runtime. Within the call the shared package can cre- 
ate an environment for itself, register it and fulfill the re- 
quested service. Upon return the applet can save the 
package environment in its designated node and register 
its original environment. From now on the applet must 
always save its environment on the stack and register the 
package environment before it invokes the target pack- 
age. Ifthe runtime provides a garbage collector, both the 
applet and the shared package can allocate local objects 
which are not part of the environment and are garbage 
collected after the current invocation of the applet. As 
the applet is in control of the shared package environ- 
ments, it can reset their roots any time during the session 
and thus subject them to garbage collection. This allows 
the optimization of memory usage for instance when an 
applet uses multiple packages alternately during a ses- 
sion. The same mechanisms apply in the second scenar- 
i0. 

The third scenario demands extending the transient 
environment lifetime over an applet session. This is 
achieved by either requiring the applet to not reset its 
transient environment at the end of the session or using 
a system method to retrieve it. The longer living envi- 
ronment can then be shared by the collaborating applets. 
They manipulate it alternately until the last deselected 
applet during the collaboration finally resets it. The 
runtime may then free the transient space for the next 
session. 


7.2.2 Multiple Transient Environments 


Collaborating applets may have different transient 
environments causing the runtime to support multiple 
transient environments at a time. Each collaborating ap- 
plet creates and registers its own transient environment 
with the runtime system and extends its lifetime to last 
longer than its current session. The runtime switches be- 
tween the transient environments whenever an applet is 
deselected and the next applet during the collaboration 
is selected. When the last deselected applet resets its 
transient environment the runtime releases the transient 
space. If a garbage collector exists, parts of the transient 
space can be reclaimed when any applet resets its tran- 
sient environment. 

The support of multiple environments can be useful 
in the second scenario to simplify programming and to 
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encourage the full use of all available RAM. When acli- 
ent applet requests a reference from a server applet, the 
request is forwarded by the runtime to the serving ap- 
plet. The server applet creates and initializes its own 
transient environment, registers it with the runtime and 
retums a reference to the requested shared reference. 
The runtime marks the serving applet as being part of 
the current session and forwards the reference to the cli- 
ent applet. Whenever the client invokes a method on the 
server reference the runtime switches to the appropriate 
transient environment. The server object can access its 
transient environment and use it to execute the request- 
ed service. When the client applet is finally deselected, 
all transient environments of the participating server ap- 
plets are also reset. ; 

As opposed to the single transient environment the 
management of the individual environments is up to the 
Java Card runtime. This simplifies the programming 
model but limits the control of the executing applet over 
memory utilization. The Java Card runtime is not able to 
release any of the participating environments prior to 
the end of the session without the support of the shared 
services or the request of the currently selected applet. 


7.2.3 Limitations of Transient Data Sharing 


The static memory model of the transient data ap- 
proach fails to provide a flexible use of transient data in 
any of the three scenarios. 

For the first scenario, a shared package can only al- 
locate transient data if it is called during the installation 
of the applet. Moreover, it must connect its transient 
data to the persistent set for later use. 

For the second and third scenarios, both the shared 
object and the collaborating applets have to keep their 
transient information in globally reserved ‘‘clear on re- 
set’’ arrays. A shared object cannot use the ‘‘clear on 
deselect’’? arrays of its implementing applet as the 
“‘clear on deselect’’ space is reserved for the currently 
selected applet, the client applet. This forces either the 
global reservation of RAM by allocating ‘‘clear on re- 
set’’ arrays or the renunciation of transient data. In the 
first case shared applets can hog RAM causing denial of 
service problems by preventing installation of any client 
applet. In the second case the performance of EEPROM 
will prevent the sharing of any complex services and 
force each client to implement parts of or even the 
whole service, defeating code reuse. 
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8 Conclusions and Future Work 


The contributions of this paper are: 
¢ We suggest a terminology and framework with 
which to describe the issues underlying memory 
models in Java Card. 


We identify the restriction that can be placed on 
orthogonal persistent systems while retaining all 
the benefits of persistent systems for the Java 
Card programmer. 


We have presented other solutions attempting to 
solve the problems of transient data and shown 
their weaknesses. In particular we have shown 
that the static memory model described in the 
Java Card 2.1 Specification results in an unusual 
programming model and restricts the possibili- 
ties for memory reclamation and object sharing 
to an unsatisfying degree. 


We have shown that, by making support for tran- 
sience explicit, a Java Card can provide a scal- 
able API that can allow the manipulation of 
transient data similar to the standard Java envi- 
ronment. The resulting dynamic memory model 
naturally fits Java Card’s execution model, 
allowing the simple and effective deployment of 
a garbage collector and enhances object sharing. 


The proposed environment has been implemented 
and tested on a number of applets. In the future we hope 
to provide concrete benchmarks supporting its simplici- 
ty and performance to enable comparison of the design 
choices. We hope the transient environment will further 
demystify smart card programming and permit Java 
Card programmers to truly enjoy the benefits of persis- 
tence. 
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Abstract 


This paper proposes a new approach for the 
role of smartcards into distributed and mobile 
service environments. It is based on the nam- 
ing and directory service architecture. We 
present a naming and directory service ar- 
chitecture which is based on a new compo- 
nent we named Personal Naming and Direc- 
tory Service (PNDS), which is embedded on 
a smartcard. In section two, after a short in- 
troduction, we present PNDS concept and list 
advantages to have it stored on a smartcard. 
Section three gives an overview and limits 
of current smartcards applications for mobile 
users. Section four presents PNDS features 
more precisely, and shows how it has been in- 
tegrated into a federated architecture of nam- 
ing servers (PNDS has been prototyped us- 
ing a GemXpresso JavaCard platform). To 
demonstrate the PNDS concept, an example 
of a PNDS-based application is presented in 
section five. 


1 Internet Services 
and User Mobility 


With the growth and spread of the Inter- 
net. vast information resources and services 
are making available to anyone, at any time, 
from anywhere in the world. People and 
businesses are becoming increasingly depen- 
dent on rapid and easy access to information 
drawn from both local and global sources. 
As more and more people and places become 
* connected”, technological needs and market 


forces continue to change at an increasing 
pace. 


The Internet community currently focuses 
part of its forces on the convergence of fixed 
and mobile networks to provide access to the 
Internet from wireless terminals (e.g., cellular 
phones, pagers, in-car computers, palm-top 
computers). Internet Engineering Task Force 
(IETF) is chartered to develop or adopt ar- 
chitectures and protocols to support mobil- 
ity within the Internet [1]; World Wide Web 
Consortium (W3C) is working towards mak- 
ing information on the World Wide Web ac- 
cessible to mobile devices [2]; WAP Forum 
(Wireless Application Protocols) [8] is defin- 
ing de-facto world standard for wireless in- 
formation and telephony services on digital 
mobile phones and other wireless terminals; 
Co-operation between W3C and WAP Forum 
has started around a common test bed [4]. 


This convergence of system and network in- 
frastructures leads to offer on-line access to 
mobile users regardless their physical location 
and the serving network, and through various 
types of terminal devices having different ca- 
pabilities and interfaces. Therefore. mobile 
users will need intelligent information han- 
dling to easily access information and services 
and customize terminals and applications ac- 
cording to their own preferences (user pro- 
files). 


This paper proposes a new approach for the 
role of smartcards into these distributed and 
mobile service environments. This approach 
is based on the naming and directory service 
architecture. We present a naming and direc- 
tory service architecture which is based on a 
new component we named Personal Naming 
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and Directory Service (PNDS), which is em- 
bedded on a smartcard. In section two, after 
a short introduction, we present PNDS con- 
cept and list advantages to have it stored on 
a smartcard. Section three gives an overview 
and limits of current smartcards applications 
for mobile users. Section four presents PNDS 
features more precisely, and shows how it has 
been integrated into a federated architecture 
of naming servers (PNDS has been proto- 
typed using a GemXpresso JavaCard plat- 
form). To demonstrate the PNDS concept, 
an example of a PNDS-based application is 
presented in section five. Finally, we conclude 
with future directions. 


2 Naming Services 


With the emergence of the Internet and dis- 
tributed object technologies, naming services 
have become essential elements in distributed 
system architectures. Naming Services make 
possible communication, data exchange and 
co-operation among different distributed ob- 
jects by providing name-to-object resolution. 
Moreover, naming services provide founda- 
tion for more evolved services such as Direc- 
tory Services and Trading Services. 


2.1 Naming & Directory Services 


Naming services provide objects from a re- 
quest which has a name as an argument. A 
naming server manages a hierarchical struc- 
ture of objects, and provide navigation facil- 
ities over a logical graph naming of contexts 
(figure 1). 


In addition, a directory server manages a 
collection of attributes for each registered ob- 
ject. Attributes hold characteristics of ob- 
jects and allow servers to provide client with 
powerful search and filtering mechanisms on 
attributes, hence on objects. Clients specify 
search criteria with their requests, and get in 
return a list of objects which match those cri- 
teria. 


Naming and directory services can be 


USENIX Workshop on Smartcard Technology (Smartcard '99) 


Foe 


Figure 1: Graph of Naming Contexts 


viewed as special address books which are dis- 
tributed across the network and which pro- 
vide information on distributed objects. Ob- 
jects may be of different types such as for 
example IP adresses from the Domain Name 
Service (DNS) [5], CORBA Interoperable Ob- 
ject References (IOR) [6], corporate directory 
entries from an LDAP database (Lightweight 
Directory Access Protocol) [7], or personal di- 
rectory entries from a personal address book. 


The list of attributes along with their types 
depend on the type of registered objects. For 
example, in case of an address book, e-mail 
and phone-number are attributes of a person 
entry; in case of a network-printer directory 
service, printing-quality (laser vs. dot- 
matrix) is an attribute for a printer entry: in 
case of a user profile, prefered-colors and 
languages are attributes for a particular user 
service. 


Combining objects with attributes allows 
servers to provide each time an adapted ser- 
vice. Trading Services benefit from these fea- 
tures and provide users with features to dis- 
cover and access to new services according to 
their types and characteristics. 


2.2 LDAP 


Even if many naming servers have already 
been implemented for a while such as Do- 
main Naming Service (DNS), Network In- 
formation System (NIS), or CORBA naming 
service (COS), LDAP is a new emerging nam- 
ing and directory service. 


The main interest of LDAP consists of flex- 
ibility. All current naming services can be im- 
plemented with this protocol. The structure 
of an LDAP service is based on a hierarchy 
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Figure 2: Referral vs. Referred Context 


of entries made of attributes and bound ob- 
jects. The lookup of objects and the search 
according to filters on attributes provide with 
convenient accesses [8]. Access controls are 
supplied by identification and authentication. 


Interesting features of LDAP include the 
support of Referrals Conterts. This special 
type of entry is used to forward requests to 
other naming servers on the network when 
the current server cannot provide with the re- 
quested object. With referrals, different nam- 
ing spaces from different naming servers can 
be linked together (figure 2). Referral entries 
also allow to share data among several users 
and make easier global updates on distributed 
databases. 


We have chosen LDAP protocol as a refer- 
ence for the Personal Naming and Directory 
Service (PNDS). 


3 PNDS 


Naming and directory services are tradi- 
tionally supported by network servers and are 
provided to users as part of their network and 
service provider subscription. 


However. on-line connections and services 
evolve to become more personalized to users 
and available at anytime from anywhere. The 
concept of Personal Naming and Directory 
Service (PNDS) was developed to provide 
mobile users with the part of naming and di- 
rectory service that may be private and per- 
sonalized. PNDS is implemented on a smart- 
card and is fully integrated in the overall 


naming and directory architecture through 
referrals (figure 3). 


PNDS is a generic component which is able 
to store a hierarchical directory of bound 
objects along with pairs of attribute-value. 
Therefore, PNDS is perfectly suited to store 
various kind of users’ or network related data, 
such as for example : 


@ object references (e.g., network ad- 
dresses) which allow the system and net- 
work to bind to remote services, 


e user service profile entries, which person- 
alize services the user has subscribed to, 


e Users’ personal applications such as for 
example a personal address book. 


3.1 Three Modes of Operation 


The PNDS leverages the LDAP concept of 
referrals by handling three modes of opera- 
tion. 


1. When set in the Referral Ignore mode, 
PNDS ignores every referral, and direc- 
tory lookups are perfomed locally in the 
smartcard. This is especially useful when 
the network is unreachable, or if the user 
does not want to open a network connec- 
tion. 


2. When set in the Referral Throw mode, 
PNDS throws an exception at destina- 
tion to the client application as soon as 
it traverses an object bound to a refer- 
ral. The client application can choose to 
open a network connection, and request 
from the PNDS the remaining part of the 
query to complete the lookup, as well as 
the address to contact the server. 


3. When set in the Referral Follow mode, 
PNDS is able to follow referrals on its 
own. Without informing the client ap- 
plication that the requested object is lo- 
cated on a remote server, PNDS requests 
the hosting terminal to open a network 
connection and forward the request. 
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An example of using such a feature is when 
the user wishes to access a specific service. 
As the required service information may al- 
ready be stored on the smartcard (service 
profile), the first lookup to the PNDS can 
be performed using the Referral Ignore mode. 
Depending on the result, a second attempt 
will be issued using Referral Throw or Refer- 
ral Follow modes, to link to the network and 
retrieve service profile information from the 
referred server. 


Data from the PNDS can be updated either 
by service providers/administrators from the 
network, or directly by users themselves from 
the client application on the terminal. A se- 
curity model for access controls will have to 
be provided (see section 7). Therefore, it will 
be possible to bookmark the result of queries 
locally on the PNDS smartcard for next uses. 


3.2 Remote Attributes 


Due to their tiny size, smartcards have in- 
herent limitations in term of memory capac- 
ity (see section 4). Thus, we have introduced 
the concept of Remote Attribute to reference 
object attributes which are located remotely 
on external content servers (figure 3). Com- 
monly, a reference attribute will be stored as 
a URL, but any other addressing schemes can 
be supported (e.g. phone number’). 


Naming & Directory . 
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Figure 3: A Personal Naming & Directory 
Service 


1It is possible to use URL addressing scheme to 
reference any content and services, as for example in 
WTA telephony services specification from the WAP 
Forum. 
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4 SmartCards 
for Service Personalization 


A smartcard is a plastic card with an em- 
bedded microprocessor and memory which 
allows it to store data and execute code. 
The main concerns about smartcard include 
data confidentiality, secure authentication 
and high computing mobility (due to its small 
and convenient size). The current limits are 
restricted memory (up to 32Kb). 


Current types of smartcards are based on 
either a file system [9], a small SQL-based 
database [10], or a virtual machine based op- 
erating system such as the JavaCard [1]]. 
This last type of smartcards allows service 
downloading and is well-adapted for the de- 
velopment and deployment of new applica- 
tions. Development and integration of ser- 
vices in such a JavaCard can be full object- 
oriented, hence the integration in distributed 
systems is made easier. Therefore we have 
chosen the Gemplus GemXpresso JavaCard, 
which provides full object-oriented design and 
programming model [12]. 


4.1 Current Applications 
for Mobile Users 


As far as network access is concerned, the 
SIM card [13] is certainly today the most 
widespread smartcard. SIM cards allow mo- 
bile users to access the GSM network [14]. 
Upon entering a PIN code, user is identi- 
fied and authenticated, and access is granted 
whatever the GSM terminal used. Moreover, 
the SIM card is used to store and provide 
users and terminals data such as personal ad- 
dress books and small interactive applications 
[15]. 


More recently, smartcards which support 
public-key algorithms are being deployed to 
provide Internet security to users [16]. These 
type of cards generate the private and public 
keys on their own. The public key can then 
be exported as acertificate (e.g., X500), while 
the private key will never be released outside 
of the card. 
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4.2 Limits of Current Network- 
Oriented SmartCards 


Current smartcard applications allow ter- 
minal personalization. When the card is in- 
serted, an anonymous terminal can become a 
personalized terminal. However, this person- 
alization capability is still not widely used. 
Main smartcards concern is limited to secu- 
rity. 


Smartcards provide data storage, but cur- 
rently only the file and directory structures 
for binary data is deployed. This reduces the 
role of the card as asimple binary data server 
and therefore such a card cannot act in a full 
co-operation within architectures of open ter- 
minals, networks, systems and services. 


The naming approach applied to the smart- 
cards makes them more adapted to dis- 
tributed environments. A naming environ- 
ment provides to the terminal all personal- 
ized information with a better interface than 
a file system. Powerful searches and referral 
entries make easier the integration of such a 
smartcard into distributed systems. 


4.3 Benefits for Mobile Users 


PNDS extends users’ mobility because the 
part of users’ personal and private informa- 
tion is easily and securely carried-on from ter- 
minal to terminal. The benefits for mobile 
users are at least threefold. 


e Access from different access points 
and terminals: Users can access ser- 
vices from different terminals and _ lo- 
cations (e.g., network computers), and 
keep each time their own personalized 
features. Also, services can be adapted 
according to resources available locally. 


e Access in stand-alone: Users can ac- 
cess part of their private and personal 
information securely, even in stand-alone 
mode, without any network elements or 
data involved. 


e Security: The potential threat to in- 
dividual privacy makes end-users wary 


about sharing personal information [17]. 
Storing personal and private information 
into a secure and tamper resistant device 
(i.e., a smartcard), allows the control of 
information exchange by means of user, 
application, and/or system level authen- 
tication. 


5 A PNDS Implementation 


The PNDS is an individual naming server 
with a similar approach to LDAP embedded 
into a smartcard’. This service must be sup- 
plied in any circumstances. The smartcard 
iS an appropriate support to provide such a 
personal naming server for mobile users, as 
it contains the personalization part of mobile 
users’ services. 


A directory structure like LDAP appears 
to be a solution to propose different naming 
spaces to different services. A naming space 
is defined by a directory entry. 


5.1 GemXpresso JavaCard 


The PNDS has been prototyped on a 
GemXpresso: the Gemplus’ 32-bit RISC 
JavaCard. ‘This card allows one to easily 
write a card applet in Java language and to 
invoke it through a generated Java proxy. 
The client application invokes Java object 
methods without being aware of the specific 
smartcard commands. 


The PNDS is made of directory entries in a 
hierarchical structure. Each entry contains a 
list of attributes. The design was made with 
the concern to save memory in the card and 
to have a better execution speed. Thus, a spe- 
cial attribute is referenced as the entry name, 
and binding an object to an entry is perfomed 


?Even if the PNDS is similar to a smartcard- 
embedded LDAP server, the set of commands is spe- 
cific. Due to today’s smartcard memory capacitylimi- 
tation, a real LDAP implementation into a smartcard 
is impossible. Furthermore smart card communica- 
tion protocol is different (actually it is not TCP/IP). 
Thus, the integration of such a server appears to be 
an impossible challenge. 
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by adding an attribute. An attribute consists 
of a name-value pair. For example, an entry 
corresponding to a person description could 
be as it follows. 


cn = Durand /* common name (entry name) */ 
gn = Pierre /* given name */ 
1 = Paris /* location */ 
pn = +33 4 12 34 56 78 /* phone number */ 
m = pdurandégemplus.com /* e-mail */ 


Searching an entry in a directory is carried 
out by a search engine implemented in the 
smartcard. This search engine provides a list 
of entries matching attribute criteria. 


A request to get, add or modify an entry is 
allowed only after being authenticated by the 
user’s password. 


5.2 PNDS Integration 
into Distributed Systems 


A common interface for Java objects has 
been defined by several international compa- 
nies to unify the access to different types of 
naming and directory services. This interface 
is named JNDI [18] (Java Naming and Direc- 
tory Interface). JNDI supports are available 
for major naming and directory servers (e.g., 
X500, LDAP, NIS, COS). 


We decided to choose JNDI to realize the 
PNDS integration into distributed systems 
because this model proposes a way to feder- 
ate all naming servers. PNDS appears to be 
just a new naming and directory server to be 
integrated within this framework (figure 4). 


In addition to the PNDS_ embedded- 
smartcard server, and like the other nam- 
ing services, we have developed a JNDI SPI 
(Service Provider Interface) [19], outside the 
smartcard, to request the PNDS. A client ap- 
plication invokes JNDI methods to the PNDS 
like other naming servers without being aware 
of PNDS smartcard requests. 


For example, a client application can 
call the lookup(), the getAttributes(), 
or the list() methods, to lookup, re- 
trieve attributes. or list sub-entries of 
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Figure 4: PNDS Integration into JNDI 


a particulary entry. Also, by call- 
ing the createSubcontext() or the 
modifyAttributes() methods, the client 
application can create new objects/entries 
in the graph, or create, modify or remove 
attributes of an entry. 


The DirContext Java class, which has 
been implemented, converts standard JNDI 
commands to PNDS requests to a GemX- 
presso smartcard proxy. Implementation of 
the InitialContextFactory JNDI interface 
provides PNDS initial contexts, that is to say 
the way to access and send requests to the 
PNDS. 


5.3 Federating Naming Services 


As explained previously, implementing a 
JNDI interface to the PNDS supplies client 
applications with a unique interface. How- 
ever the JNDI API allows the management of 
referrals. A JNDI referral context references 
another context. This context may be on the 
same server or on a different one. This other 
server may host a different type of naming 
service (e.g. COS, LDAP, ...). 


A PNDS entry is a referral entry when it 
contains a referral attribute with a reserved 
name and an address to the referred context. 
When a request needs to explore an entry 
bound to a referral entry, the behaviour of 
PNDS depends on the mode of operation that 
is currently set? 


3A different operation mode can be set at each 
request. 


USENIX Association 


USENIX Association 


e REFERRAL_THROW or REFERRAL_FOLLOW?: 
an exception is raised to the PNDS- 
SPI interface. This interface generates a 
JNDI ReferralException to the client 
application references and data delivered 
by the PNDS. The client can invoke 
the getReferralContext() of this ex- 
ception to easily get the referred context. 


e REFERRAL_IGNORE: PNDS ignores the re- 
ferral and continues to descend the di- 
rectory hierarchy, trying to find the re- 
quested entry locally. Depending on the 
result, the requested object or NOT_FOUND 
is returned. 


The PNDS is not only a naming and direc- 
tory server, but also an access point to other 
naming servers. The PNDS contains both 
personal named objects and links to other 
named objects managed by other servers out- 
side the smartcard. 


6 Example of 
PNDS Application 


To demonstrate the PNDS features and ca- 
pabilities, we have developed a personal ad- 
dress book as an example of an application 
(figure 5). This PNDS-based application con- 
tains two parts. 


1. The first part. the address book itself, 
supplies mobile users with a set of person 
information, classified in a hierarchical 
structure composed of person entries and 
directory entries. Entries which are pri- 
vate to the user are stored locally on the 
PNDS smartcard, while shared or public 
entries are bound to referrals. 


2. The other part provides user profile in- 
formation dedicated to personalize the 
address book user interface on the ter- 
minal according to user’s preferences. 


4REFERRAL.FOLLOW has not yet been implemented. 
Smart cards such as those supporting the SIM Toolkit 
API [15] are appropriate candidates for implementing 
this type of card-driven action towards the terminal 
and the network. 


(Note that in our example, we did not 
use any referral or remote attribute in 
user profiles. but of course this can be 
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Figure 5: the Personal Address Book 


This application is an appropriate PNDS 
demonstration. It must be available from 
anywhere whatever the terminal used. As op- 
posed to the address book application code, 
address book data are personal. This requires 
features showing the advantages of PNDS and 
smartcards. 


Via the PNDS, the address book applica- 
tion accesses data located on external nam- 
ing server without being aware of requests 
to remote servers. Actually. as the address 
book data are distributed over the network, 
the PNDS opens the door to a worldwide per- 
sonal address book. 


6.1 PNDS as a Personalized and 
Private Secure Data Server 


The PNDS provides information which en- 
ables users to browse their address book over 
a hierarchical structure of entries, from a di- 
rectory entry to another. Users can select 
a person entry (a leaf of the structure), to 
retrieve its related information. A person 
entry consists of a set of attributes such as 
the common name (cn), given name (gn), 
phone number (pn), e-mail (mail) and photo 


(j pegphoto). 


The PNDS can be viewed as an opened and 
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powerful secure data server, not only as a sim- 
ple and closed secure data provider such as in 
a traditional file system. The PNDS is a full 
naming and directory server. 


In addition to the lookup(), the PNDS 
provides a search() command to find out 
person(s) into the directory structure accord- 
ing to conditions on attributes. For example: 
gn=Pierre or pn=+33 4 42*. 


Furthermore, the semantics of some entries 
may be different. For instance, Gemplus cor- 
porate directory has not to be stored inside 
the smartcard because it is provided and sup- 
ported as part of the Gemplus’ information 
system on the network. Thus in our case, 
just a referral entry is stored in the PNDS for 
Gemplus R&D directory entry. When this en- 
try is selected, PNDS provides all necessary 
information to the JNDI naming manager 
to transparently forward requests to Gem- 
plus’ server (REFERRAL_THROW). If the mode 
is set to REFERRAL_IGNORE, PNDS provides 
the Reception Desk entry (pn). 


Finally, some attributes of a person entry 
may be too large with respect to smartcard 
features. For example, attributes such as pic- 
tures or home-pages cannot be stored on the 
smartcard. However a picture attribute is 
bound as a remote attribute to the picture 
provided by a content server on the Internet. 


The PNDS smartcard is one part of a per- 
sonal address book distributed on the Inter- 
net. PNDS acts as a federation component. 


6.2 User Profile Management 


PNDS provides also an appropriate sup- 
port to personalize an anonymous terminal 
with user profiles. We have decided to man- 
age two levels of user profiles: 


e a general user profile, which contains in- 
formation related to user’s general de- 
scription and preferences, 


e aservice-specific user profile, which con- 
tains information to personalize a partic- 
ular service. 
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In our example, the general profile is im- 
plemented by a directory entry created as a 
subdirectory of the PNDS root. This entry 
named UserProfiles (UP) provides informa- 
tion attributes related to the PNDS holder 
such as his/her common name (cn), given 
name (gn), and preferred language (1g) (fig- 
ure 5). All these data describe the user. 


We chose to store user profile informa- 
tion related to the address book directly as 
attributes to the PersonalAddressBook en- 
try (AB). These attributes consist of the in- 
formation to personalize the address book 
user interface according to the user’s pref- 
erences such as foreground color (fgcolor), 
and background color (bgcolor) (figure 5). 


Also, when services themselves are not 
part of the PNDS smartcard, user service 
profiles can be specified by creating new 
UserProfile subdirectory entries (e.g., S1, 
$2 on figure 5). 


6.3 Perspective of this Application 


As an extension to our demonstration, we 
plan to integrate our personal address book in 
an e-mail manager such as Netscape Commu- 
nicator which supports access to LDAP direc- 
tory servers on the Internet. In the latest 4.5 
version, this application supports the notion 
of Roaming Access for roaming users to re- 
trieve user profile information from any place 
on the network. 


At each new connection from an anony- 
mous terminal (e.g. a public network com- 
puter), users must manually enter an LDAP 
server address along with a distinguished 
name (dn), in order for the application to re- 
trieve their profile and set their preferences 
accordingly. However, since relatively few 
users know their distinguished name, and 
probably fewer can type it correctly. this 
manual configuration may be tedious and can 
easily be replaced by just inserting a smart- 
card into a smartcard reader. 


Also, accessing the Internet from anywhere 
at anytime should allow users not only to re- 
trieve their personal preferences but also to 
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benefit from features and services which are 
available locally, provided as part of the local 
network or service provider. 


A plugin can allow Netscape Mail to ac- 
cess the address book service from the PNDS, 
and update the current configuration. Thus, 
when users insert their card into a terminal. 
the Netscape mail address book will be per- 
sonalized from the PNDS. 


7 Perspectives on Security 


Security should play a central role in 
the Personal Naming and Directory Service. 
However, scope of this paper is only limited 
to decribe PNDS itself and its integration 
into distributed systems. Therefore, we fo- 
cuse our discussion on presenting only some 
possible mecanisms to deploy security within 
the PNDS. We consider the following security 
concerns : 


e Controling the accesses to the PNDS and 
its data, 


e The role of the PNDS in the overall se- 
curity architecture of a distributed appli- 
cation. 


7.1 Access Controls 


Access to the PNDS information is cur- 
rently permitted after typing the right PIN 
code, nothing is supplied otherwise. How- 
ever a PNDS may consist of several services 
for various external applications with differ- 
ent types of accessing users. Access to pieces 
of information may require a specific autho- 
risation. 


A first approach of this problem may lead 
to identify two kinds of users, each one hav- 
ing a different level of access privileges to 
read/write parts of the PNDS : 


1. a cardholder level, which allow users 
to modify entries from their personal 


profiles and applications (e.g., Personal 
Address Book), 


2. an administrator level (i.e., network 
and/or service providers), which allow 
service/network providers to remotely 
manage (update) service profile entries. 


Different PIN codes can be assigned to dif- 
ferent privilege levels, and access conditions 
have to be set at the context level. 


7.2 Security Architecture 


The other perspective concerns the overall 
security of distributed applications. Exten- 
sive security can be implemented for naming 
and directory services. PNDS can act as a 
keys and certificates provider, and is able to 
use cryptographic features provided as part 
of the smartcard operating system. 


Possible roles of PNDS in the security of 
distributed application over the Internet are 
illustrated on figure 6. The Secure Socket 
Layer (SSL) is used to authenticate users to 
other naming servers on the network (i.e., re- 
ferrals), while the Remote Keys Encryption 
Protocol (RKEP) [20] is used to secure con- 
tent (i.e., cipher/decipher mail folders). Part 
of such a security architecture has already 
been demonstrated by Gemplus in the Vault 
prototype [21]. 
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Figure 6: Example of PNDS-based Security 
Architecture 
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8 Conclusions 


Providing an adapted and personalized ser- 
vice is not limited to just only taking into 
account users’ preferences. With the con- 
vergence of different network infrastructures, 
systems and terminals, this problem encom- 
passes network profiles, terminal profiles, and 
of course smartcard profiles. These include 
hardware and software profiles and finally 
users’ profiles. which can be partly carried- 
on within the smartcard. Providing a service 
matching the devices capalities and users’ 
preferences at each connection. is one of 
the today’s challenge on network convergence 
(figure 7). 


Service able to be provided 









Pad 
User’ smart Card 


Terminal 


Figure 7: Adaption of Services 


PNDS-based smartcard is an interesting 
concept for profiling aspects. It proposes a 
flexible structure based on a naming and di- 
rectory service for applications and systems 
on the terminal. PNDS allows the integra- 
tion of user profiles in an anonymous termi- 
nal, and personalizes the terminal and its ap- 
plications with both information stored inside 
the card and references to personal data on 
the network. 


PNDS is a generic component that is able 
to store any kind of objects, and referrals to 
objects accessible on the network are imple- 
mented both to get an infinite data memory 
capacity and to share data between several 
people. 


Furthermore, PNDS has been integrated in 
a global framework and architecture based on 
a unified application programming interface 
(API). This means that client applications in- 
voke PNDS as any other servers, without be- 
ing aware of PNDS smartcard specific com- 
mands. 
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In this prototype, access control has been 
limited to PIN code authentication. Next 
step would be to refine the security, and de- 
fine a security model for accessing and modi- 
fying PNDS local and remote objects. 
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Abstract 


This paper presents actual results from monitoring 
smartcard power signals and introduces techniques that 
help maximize such side-channel information. Adversar- 
ies will obviously choose attacks that maximize side- 
channel information, so it is very important that the 
strongest attacks be considered when designing defen- 
sive strategies. In this paper, power analysis techniques 
used to attack DES are reviewed and analyzed. The noise 
characteristics of the power signals are examined and an 
approach to model the signal to noise ratio is proposed. 
Test results from monitoring power signals are provided. 
Next, approaches to maximize the information content of 
the power signals are developed and tested. These results 
provide guidance for designing smartcard solutions that 
are secure against power analysis attacks. 


1.0 Introduction 


Cryptographers have traditionally analyzed cipher sys- 
tems by modeling cryptographic algorithms as ideal 
mathematical objects. Conventional techniques such as 
differential [1] and linear [2] cryptanalysis are very 
useful for exploring weaknesses in algorithms repre- 
sented as mathematical objects. These techniques, how- 
ever, cannot address weaknesses in cryptographic 
algorithms that are due to a particular implementation in 
hardware. The realities of a physical implementation can 
be extremely difficult to control and often result in the 
leakage of side-channel information. Techniques devel- 
oped in [3] show how surprisingly little side-channel 
information is required to break some common ciphers. 
Attacks have been proposed that use such information as 
timing measurements [4,5], power consumption [6], 
electromagnetic emissions [7] and faulty hardware [8,9]. 
Eliminating side-channel information or preventing it 
from being used to attack a secure system is an active 
area of research. 


A growing number of researchers are beginning to 
address this issue of implementation. Systems that rely 
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on smartcards to provide security are of particular con- 
cern. In such systems, smartcards are often viewed as 
tamper-resistant devices that are secure against all but 
the most determined and well-financed attackers. How- 
ever, this reliance on the tamperresistance of smartcards 
needs to be carefully scrutinized [10]. This becomes 
even more important in light of the recent attacks using 
side-channel information. It is often the case that impor- 
tant data stored on smartcards, such as a cryptographic 
key or an authentication certificate, needs to be kept 
secret to prevent counterfeiting of cards or the breaking 
of a system’s security. Examples of smartcard systems 
that rely on the secrecy of the data resident on smartcards 
can be found in [11]. Such systems are potentially vul- 
nerable because every time the smartcard system per- 
forms a computation using the secret data, side-channel 
information may be leaked. 


Of all the previously mentioned sources of side-channel 
information, power measurements are perhaps the most 
difficult to control. Ultimately all calculations performed 
by a smartcard operate on logical ones or zeros. Current 
technological constraints result in different power con- 
sumptions when manipulating a logical one compared to 
manipulating a logical zero. An attacker of a smartcard 
can monitor such power differences and obtain useful 
side-channel information. Differential Power Analysis 
(DPA) [6] is a statistical approach to monitoring such 
power signals from a smartcard. Kocher et al. [6] claim 
one can monitor the actions of a single transistor within 
a smartcard using DPA. In [6], the authors outline a spe- 
cific DPA attack against smartcards running the DES 
[12] algorithm. 


The purpose of this paper is to present actual results from 
monitoring smartcard power signals and to introduce 
techniques that help maximize such side-channel infor- 
mation. Whereas [3] showed how little side-channel 
information is required by an attacker, this paper takes 
the alternate approach and provides a first step towards 
showing how such information can be maximized. 
Adversaries will obviously choose attacks that maximize 
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side-channel information, so it is very important that the 
strongest attacks be considered when designing defen- 
sive strategies. In this paper, power analysis techniques 
for attacking DES are reviewed and analyzed. The noise 
characteristics of the power signals are examined and an 
approach to model the signal to noise ratio is proposed. 
Test results from monitoring power signals are provided. 
Next, approaches to maximize the information content of 
the power signals are developed and tested. These results 
provide guidance for designing smartcard solutions that 
are secure against power analysis attacks. 


1.1 Smartcard Power Dissipation 


The circuit shown in Figure 1 gives a simple lumped 
component model that is useful for understanding power 
dissipation measurements. Power dissipated by the 
smartcard can be monitored at the ground pin of the 
smartcard by using a small resistor (R}) in series between 
the Vgg pin on the card and the true ground. Current 
moving through R, creates a time varying voltage that 
can be sampled by a digital oscilloscope. The current 
flows out of the smartcard through a bond wire that acts 
as an inductor Lyng. The values of the inductor, Lyona: 
and the capacitors will determine the shape of the power 
signal that is observed at Veco: In aC MOS circuit, most 





| Smartcard 


power is dissipated when the circuit is clocked. This is 
known as dynamic power dissipation [13]. As Vgate 
changes from 0 to 5 volts, the transistors Q; and Q, are 
both conducting for a brief period causingcurrent to flow 
from Vgq to ground. Also during this time, the capacitor 
Cioad Will be discharged (or charged) causing more (or 
less) current to flow through the Vgg pin. 


Information useful to a cryptanalyst is leaked because the 
amount of current being drawn when the circuit is 
clocked is directly related to the change of state of Cjgaq 
or the resulting current drawn by the other gates attached 
to Cjoag- On a microprocessor, each clock pulse causes 
many bit transitions to occur simultaneously. In a typical 
smartcard microprocessor, a large portion of the power 
dissipation occurs in the gates attached to internal buses. 
Our experiments showed that activity on the data and 
address bus is a dominant cause of power consumption 
changes. These changes can be observed at V .cope- 


Two types of information leakage from the data bus that 
have been observed are Hamming weight leakage and 
transition count leakage. Hamming weight information 
leaks when the dominant source of current is caused by 
the discharging of Cjgag. A situation where Hamming 
weight information leaks is when a precharged bus 
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FIGURE 1. Measuring Power Consumption of a Smartcard 
All power signals in this report were measured across V..op¢ where R, was a 16 ohm resistor. A number of 8-bit 
microprocessor-based smartcards were examined and all produced results similar to those reported in this paper. 
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design is used. In this case, the number of zeros driven 
onto the precharged bus directly determines the amount 
of current that is being discharged. Transition count 
information leaks when the dominant source of currentis 
due to the switching of the gates that are driven by the 
data bus. When the data bus changes state, many of the 
gates driven by the bus will briefly conduct current. 
Thus, the more bits that change state, the more power 
that is dissipated. 


Experimental results that show transition count leakage 
from a typical 8-bit, microprocessor-based smartcard are 
given in Figure 2. In this figure, an 8-bit data byte from 
memory is transferred into a register. Initially, the bus 
contains the memory address, but after a clock pulse, the 
data from memory is put onto the bus. The magnitude of 
the voltage pulse is directly proportional to the number 
of bits that changed. Waveforms for different values of 
memory data are plotted on top of each other to effec- 
tively show this relationship. The difference in voltage 
between i transitions and i+1 transitions is about 6.5 mV. 
We observed similar plots for smartcards that leak Ham- 
ming weight information. The type of information that a 
particular smartcard leaks depends on the circuit design 
of the microprocessor and the type of operation being 
performed by the card. For instance, accessing EEPROM 
may yield different information than accessing RAM. 
Knowing which type of information is leaked will enable 
an adversary to optimize an attack strategy. 


1.2 Simple Power Analysis (SPA) 


An SPA attack, as described in [6], involves directly 
observing a system’s power consumption. Different 
attacks are possible depending on the capabilities of the 
attacker. In some situations the attacker may be allowed 
to run only a single encryption or decryption operation. 
Other attackers may have unlimited access to the card. 
The most powerful attackers not only have unlimited 
access, but also have detailed knowledge of the software 
and hardware running in the card. If an attacker can 
determine where certain instructions are being executed, 
it can be relatively simple to extract useful information. 
For example, during the PCl permutation in DES, we 
could determine the Hamming weight of each key byte 
by measuring the pulse height at the cycle of the instruc- 
tion that accesses this data. In an 8-bit microprocessor, 
knowing the Hamming weight of all eight DES key bytes 


reduces the brute-force search space from 2°6 to 
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keys depending on whether or not the parity bits are 
used. This was just an example; with algorithms using 
more key bits than DES or with triple-DES, knowing 
Hamming weight information alone does not help much 
with this type of brute-force attack. 


A more powerful attack can result if the attacker can see 
Hamming weight information about the key bytes and 
also information about shifted versions of the key bytes. 
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Number of Bit Transitions versus Power Consumption 


These results show how the data effects the power levels. The nine overlayed waveforms correspond to the power 
traces of different data being accessed by an LDA instruction. These results were obtained by averaging the power 
signals across 500 samples in order to reduce the noise content. The difference in voltage between i transitions and 


i+1 transitions is about 6.5 mV. 
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In DES, such information can be leaked when shifting 
the C and D registers. In fact, given the weight of each 
byte for eight of the C and D shifts there is enough infor- 
mation to solve for the value of every key bit using the 
equation 

Ak =D (i) 
where ® isa 56X 1 vectorof Hamming weights, w,; k 
is a 56x 1 binary vector of the key bits, kj; and A is a 
56x56 binary matrix such that A;; is 1 if and only if 
weight w; includes key bit kj. Even algorithms with more 


than 56 key bits, such as triple- DES would be vulnerable 
to this attack. 


If transition count information rather than Hamming 
weight information is available, an SPA attack can still 
be mounted, but it may be more difficult. The attacker 
would need to know the contents of the data bus before 
or after the data being sought is accessed. Many times 
this data is easy to determine because it is a fixed address 
or an instruction opcode, Attackers with access to the 
code can easily get this data and set up equations similar 
to Equation (1). Other less knowledgeable attackers may 
need to resort to trial and error to determine the correct 
equations. Due to the limited number of possibilities 
such an approach is reasonable. 


Our experiments confirmed that poor implementations 
of DES will almost always be vulnerable to SPA attacks. 
Shifting the key bytes or the use of conditional branches 
to test bit values can be especially vulnerable. Also, if the 
code or portions of the code run in variable time, power 
analysis could be used to enable a timing attack [4]. For- 
tunately, implementors of cryptographic algorithms have 
known about these issues for a number of years. Kocher 
et al. [6] reported that it is not particularly difficult to 
build SPA-resistant devices. However, the attackers 
keep getting smarter so further research and vigilance 
will always be necessary. 


1.3 Differential Power Analysis (DPA) 


A DPA attack, described in [6] and reviewed here, is 
more powerful than an SPA attack because the attacker 
does not need to know as many details about how the 
algorithm was implemented. The technique also gains 
strength by using statistical analysis to help recover side- 
channel information. The objective of the DPA attacks 
described in this paper is to determine the secret key used 
by a smartcard running the DES algorithm. These tech- 
niques can also be generalized to attack other similar 
cryptographic algorithms. 
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A DPA attack begins by running the encryption algo- 
rithm for N random values of plain-text input. For each 
of the N plain-text inputs, PTI;, a discrete time power sig- 
nal, Sj, is collected and the corresponding cipher-text 
output, CTO,, may also be collected. The power signal Sj; 
is a sampled version of the power consumed during the 
portion of the algorithm that is being attacked. The i 
index corresponds to the PTI; that produced the signal 
and the j index corresponds to the time of the sample. 
The Sj; are split into two sets using a partitioning func- 
tion, D(,-,°): 


So 
S| 


{S,|D(, 5°) = 0} 


2 
{S,|D¢,-.-) = 1} y 


The next step is to compute the average power signal for 
each set: 


Adjl= oS. Si 
| 01S; ;€ So (3) 
: 1 
Aily]l =—@ S;; 
ue. Blees « 


where |So| + |S\| = N. By subtracting the two aver- 
ages a discrete time DPA bias signal, 7[j], is obtained: 
T[j] = Ajlj]-A,L/] (4) 
Selecting an appropriate D function will result in a DPA 
bias signal that an attacker can use to verify guesses of 


the secret key. An example of such a D function is as fol- 
lows: 


D(C,, C5, Ki¢) = C,; @BSBOXI(C, ®K,,) (5) 
where 
C, =the | bit of CTO; that is XOR’ed with bit #1 of 
S-box #1 
Ce = the 6 bits of CTO; that are XOR’ed with 
subkey K16 


Ky6 = 6 bits of the 16th round subkey feeding 
into S-box #1 


SBOXI(x) = a function returning bit #1 resulting 


from looking up x in S-box #1 


The D function of Equation (5) is chosen because at 
some point during a DES implementation, the software 
needs to compute the value of this bit. When this occurs 
or anytime data containing this bit is manipulated, there 
will be a slight difference in the amount of power dissi- 
pated depending on whether this bit is a zero or a one. If 
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this difference is €, and the instructions manipulating the 
. . Fal . . 

D bit occurs at times j , the following expected differ- 

ence in power equation results: 


BS, |DC,)=0|-B[S,[DC.9=1]= © 6 
for J=J 


When j is not equal to j', the smartcard is manipulating 
bits other than the D bit, and the power dissipation is 
independent of the D bit: 


E[Si|(DC, = 0) |-E[ SiC, 9 = | 


(7) 
= 4 Sij |B] Sij) = 0 


forj#j 


As the number N of PTI inputs is increased, Equation (4), 
converges to the expectation equation: 


Jim TU] = E[ Sij|(DC, 7 0)| 


- E[ Sij|(Do +) = | (8) 


= £| Sij]-#| Sij| = 0 
Thus, a review of Equations (6), (7) and (8) shows that if 
enough PTI samples are used, 7[j] will show power 


VJ 


Round 14 


biases of € at times i and will converge to zero all other 
times. Due to small statistical biases in the S-box out- 
puts, the assumption of independence in Equation (7) is 
not completely true. In reality, 7[j] will not always con- 
verge to zero; however the largest biases will occur at 


: * 
times] . 


One input to the D function was Ky, six bits of the sub- 
key. The attacker does not know these bits, but can use 
brute force and try all oe possible values. For each guess, 
the attacker constructs a new partition for the power sig- 
natures and gets a new bias signal, 7]j]. If the proper D 
function was chosen, the bias signal will show spikes 
whenever the D bit was manipulated. If the D function 
was not chosen correctly (i.e., the wrong subkey bits 
were guessed), then the resulting 7[j] will not show any 
biases. Using this approach, an attacker can determine 
the six subkey inputs to S-box #1 at round 16 of DES. 
Repeating this approach for the seven other DES S-boxes 
allows the attacker to learn the entire round 16 subkey 
(48 bits). The remaining 8 bits can be found by brute 
force or by successively applying this approach back- 
wards to previous rounds. Figure 3 compares the bias 
signal for a correctly chosen key to that of an incorrectly 
chosen key. The signal for the incorrect key shows a few 
small biases, but the correct key has biases that are twice 
as large, so itis easily recognized. We created the signals 
in Figure 3 using N = 1300. 


Round 15 


Power Biases 


| gee Nn 
T[] (correct key): ptnanterntsenhnnai phe ann noennentes tern 


TU] (incorrect key): serena btn arn 


FIGURE 3. DPA Result Showin 


Power Bias Signals for Correct Key and Incorrect Ke 


The power biases are about 6.5 mV for the correct key and about half the size for the incorrect key. The 
voltage SNR for the correct key is 17.3. A total of N=1300 power signals were used to generate the above 


plots. 
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2.0 Noise in Power Analysis Attacks 


There is arich history of methods to reduce noise in elec- 
trical circuits. Many good textbooks have been written 
on this topic (.g., [14]). Techniques for noise reduction 
are particularly important when trying to measure side- 
channel emanations because the magnitude of these sig- 
nals can be extremely small. The DPA attack uses aver- 
aging to reduce noise, but it is important to investigate 
other strategies that may lead to further reductions in the 
amount of noise. Experts quoted in [15] report that one 
way to prevent a power analysis attack is to mask the 
side-channel information with random calculations that 
increase the measurement noise. A good understanding 
of the achievable noise levels using typical electronic 
measuring techniques is needed to evaluate the effective- 
ness of such a solution. 


2.1 Noise Characteristics 


There are four types of noise present when performing 
power analysis of smartcards: external, intrinsic, quanti- 
zation and algorithmic. External noise is generated by an 
external source and coupled into the smartcard. Intrinsic 
noise is due to the random movement of charge carriers 
within conductors. Quantization noise is due to the quan- 
tizer in the A/D that is used to sample the power signals. 
Algorithmic noise is due to the randomness of the data 
bytes being processed by the smartcard. Intrinsic and 
quantization noise are small when compared to present 
day side-channel signals, but will likely play a larger role 


Power Spectrum 


Mee 


4Mhz 8 Mhz 


12 Mhz 


as future designs minimize side-channel signals. Exter- 
nal noise can be reduced through careful use of measur- 
ing equipment, good circuit design practices and 
filtering. Algorithmic noise can be reduced if an attack 
strategy can use unbiased random data that can be aver- 
aged out. 


Figure 4 illustrates a sample of the noise measured in a 
power analysis experiment. The top waveform, Nj, was 
determined using the following equation: 


N, = EIS ,)-S, 


where the value of E[S;] was estimated by averaging the 
power traces obtained when encrypting the same input 
data 5,000 times and S; is one of the traces. Clearly any 
deviation of N; from zero should be considered noise. 
The noise shown in Figure 4 has a slow beat frequency 
around 182 Khz that could be due to external coupling 
from test equipment or more likely due to the superposi- 
tion of the digital oscilloscope’s sampling frequency and 
the smartcard’s clock frequency. The power spectrum of 
the noise also reveals significant spikes at the smart- 
card’s clock frequency and its harmonics. A close-up of 
the noise reveals that a significant amount of the noise 
energy is concentrated at the edges of the smartcard’s 4 
Mhz clock edges. 


The noise signal in Figure 4 does not contain algorithmic 
noise since the data being encrypted was kept constant. 
The effect of algorithmic noise would be to cause spikes 


182 Khz peaks 


ary 


Close-up of Nj; ml SESE T Nt eS 


4 Mhz Clock Edge 


ee 


FIGURE 4. Measured Noise in a Smartcard Power Signal 


The smartcard was clocked at 4 Mhz and the bus speed was 2 MHz. The mean and square root of the variance 
of the noise are 0.0 and 7.5 mV, respectively. The peak value of the noise is about 60 mV. 
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to appear in the portion of the signal where the data is 
being processed. These spikes could be used by an 
attacker to mark locations in the power trace that are data 
dependent. Algorithm noise can be modeled as shot 
noise using a generalized Poisson random process [16]: 


x(j) = Der s) 


In this case, ¢; is a random variable (r.v.) corresponding 
to the Hamming weight of the data being processed, j; is 
a Poisson r.v. that models the seemingly random loca- 
tions of the data dependencies and F would be the shape 
of the bias signal. If random data is used, then e; would 
have a binomial distribution. An accurate model of the 
various noise components would be very useful for sim- 
ulating the effectiveness of DPA attacks and solutions. 


2.2 Filtering the Noise 


Filtering strategies can be used to reduce the noise shown 
in Figure 4, but care needs to be taken so that the compo- 
nents necessary to create a power bias signal are not 
affected. The algorithmic noise can be reduced by aver- 
aging using unbiased random data. Filtering will not 
work on algorithmic noise because any filter would also 
reduce the desired bias signal. If the noise in Figure 4 is 
assumed to be white noise, then the optimal filter that 
maximizes the signal-to-noise ratio (SNR) is the 
matched filter. We designed and tested such a filter for 
the bias signal shown in Figure 3. The original voltage 
SNR was 17.3. After using the matched filter, the SNR 
was increased to 23.2. This gives some indication of how 
much an attacker with a perfect matched filter can 
improve the SNR. 


2.3 The Effect of Averaging 


A DPA attack is successful because averaging reduces 
noise energy, thus revealing any concentrations of signal 
energy that occur at constant positions in time. To see the 
effect of averaging on the noise refer back to 
Equation (3). Let the average variance of Sij be o” and 
assume Sjj is independent of Skj when ik. If the N sig- 
nals were equally split between sets Sp and Sj, then the 
variance of Ay and A; is 20°/N . Therefore, when Ag 
and A, are combined the resulting DPA bias signal has a 
variance of 40°/N . 


The averaging effect on the signal was shown in 
Equation (6) to produce a bias spike of size €. The D 
function, proposed in Equation (5), has the effect of 
fixing one bit of the data being processed. If a data word 
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is m bits wide, then the remaining unfixed bits in the 
word have an average Hamming weight of (m-1)/2 with 
a variance (i.e., algorithmic noise) of (m-1)/4. Averaging 
over N samples has a similar effect on this signal vari- 
ance as it did on the noise variance. Assuming indepen- 
dence of the different sources of noise yields the 
following signal and noise parameters: 


noise: 


B TUGes) =0 


° 402 2 
var| Pale J ] 2 decane, 
(9) 
signal: EITW'I| =€ 
a 2 
* | 40 +(m—1)e 
var| TL 1 ———— 


In the variance of the noise, the term & is the percentage 
of T[j] that is dependent on the data being encrypted, thus 
the percentage of algorithmic noise. The success of a 
DPA attack depends on distinguishing the signal from 
noise, so the final voltage SNR is: 


(10) 
807 +£°(am +m-1) 


Equation (10) can be checked with previously measured 
experimental results. Setting o =7.5 mV (from 
Figure 4), € = 6.5 mV (from Figure 2), m = 8, N = 1000, 
and a=0 yields SNR =7.5. Experimental results using 
these parameters showed a SNR between 7 and 10, thus 
confirming that Equation (10) is a valid approximation. 


3.0 Maximizing DPA Bias Signal 


One way to increase the SNR in Equation (10) is to 
increase €. The value of € is dependent on the number of 
bits output by the D function. In Equation (5), D outputs 
only one bit, but in general the D function could output d 
bits. In this general case € = dl, where / is a constant equal 
to the voltage difference seen between two data words 
with Hamming weight i and i+1. Figure 2 showed that 
these differences can be considered approximately equal, 
for all i. 


157 


When performing the differential power analysis there 3.1 4-bit DPA Attack on DES 
would be three sets used for partitioning: 


In DES, a 4-bit D function based on the four bits output 
d from an S-box can be used to partition the sets Sp and Sj. 
SS: 5.0- 1D a) = 0 ‘ ve: ‘ 
On iil INN ane Equation (5) can be modified to output four bits: 
d 
where SBOX1,(x) returns all four bits resulting from 
looking up x in SBOX #1. Similar D functions would be 


S, = S;)| Si; € SoS, used for the other S-boxes to enable all the key bits to be 
eventually determined. 


Sy 


The other DPA equations would all remain the same and The question arises as to whether Equation (12) will 
the power signals in set S, would not be used. The fol- result in partitions that are unbiased enough so that the 


lowing signal and noise equations would result: incorrect choices of Kj¢ will result in random power sig- 
nals that average to zero. A simulation was written to see 


what type of biases could be expected. The results for 4- 
bit DPA and 1-bit DPA using random PTI inputs and a 
eee wei sent typical key are graphed in Figure 5: The graph shows 
var| TL] \(j#J )| Se that the expected Hamming weight biases of the S-box 

N #1 lookup for each of the 64 possible key guesses. The 
correct key guess clearly shows the most bias; however 
in the case of 4-bit DPA there is a case where an incorrect 


noise: g[TUAGes)| = 0 


. * 
signal: ETL 1| = dl key guess has the same magnitude bias as the correct 
(11) _ key. In this case, if the attacker did not know the sign of 
var[ TU) a 40” +(m—- yl” the expected bias, a very small brute-force search might 
N be needed. 


3.2 Multiple Bit DPA 


SNR = peace Nl In general, other multiple bit D functions can be defined. 
J 80° + (am +m-1) In software implementations, the S-box lookups are per- 
formed using a load instruction from a table storing all 


4-bit DPA 


1-bit DPA 


"50 


Correct Key 
FIGURE 5. DPA Biases Generated for DES Key = 01 23 45 67 89 ab cd ef 


The Y-axis indicates the amount of bias each 6-bit DES key guess will generate. The correct key generates the 
most bias and the other keys show smaller biases. These results were obtained by simulating the bias using 500 
random PTI inputs and looking at the bias at S-box #1. 
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TABLE 1: 


Piao pasa fo a osen| cae | oe 


TABLE 2: 





Attack | Attack Type: _| | __1-bitDPA _| -bit DPA 4-bit DPA | __8-bit DPA _| bit DPA Address DPA 





’ Signal Levely | 335mV | 795mV | _74.4mV 


the S-box data. To compress the table size, the four bit S- 
box data is frequently stored in pairs of two or more, 
depending on the word size of the processor. If the 
attacker knows how the S-box data is packed into this 
table, it would be possible to maximize the bit biases 
even further. For example, power signals with S-box 
lookups that yield many zeros can be separated from sig- 
nals with S-box lookups containing many ones. Again, 
the number of bits that can be biased will proportionally 
increase the SNR. 


Another way to mount an attack would be to partition Sp 
and S; based on the addresses used for the S-box lookups 
rather than the data. The attacker forms two partitions, 
one that maximizes the number of address bus transitions 
and one that minimizes the number of address bus tran- 
sitions. Power signatures from both partitions are aver- 
aged and then subtracted. If the address bus is larger than 
the data bus, even larger biases could be achieved. 


When mounting a d-bit DPA attack the attacker may 
need to use more power signals. After all, an average of 
1-2'4 of the power signals are placed in partition S, and 
are unused. This suggests that an attacker cannot 
increase d too much without requiring an excessive 
number of power signals. An attackerrunning 1-bit DPA 
using N signals would need Nj = 24 Nid? power signals 
to maintain the same SNR when running d-bit DPA. 
Table 1 shows that for small values of d actually fewer 
power signals are necessary and with 8-bit DPA only 
twice as many signals are needed. The main advantage of 


Probability 


d-bit DPA is that the resulting signal levels are magnified 
d times. 


Experiments were run on a smartcard to confirm the 
effectiveness of 4-bit, 8-bit and address-bit DPA. The 
resulting signal levels are shown in Table 2. In these 
experiments, the 8-bit DPA attack was only able to create 
an average bias of 6.0 bits because the S-box data was 
never all zeros or all ones. The address-bit DPA had sim- 
ilar problems so only an average bias of 6.5 bits was 
achieved. As can be seen the signal levels for these mul- 
tiple bit DPA attacks are much stronger. It is clear that 
countermeasures to DPA attacks need to consider all 
these more powerful attacks. 


3.3. Hiding the DPA Bias Spike 


One suggested solution to prevent DPA attacks is to add 
random calculations that increase the noise level enough 
to make the DPA bias spikes undetectable. The results 
presented in this paper give some indication of how 
much noise needs to be added. The main goal is to add 
enough random noise to stop an attack, but to add mini- 
mal overhead. A rough approximation of the noise nec- 
essary can be found by looking at the probability density 
function (p.d.f.) of the DPA bias signal plotted in 
Figure 6. The DPA spike obviously stands out from the 
noise because it is very improbable that it was generated 
by noise. Ideally, the p.d.f. of the bias signal would 
stretch out to cover the DPA spike or the DPA spike 
would be reduced so that it is closer to the noise. One 


DPA Bias Spike 


' 


3 
Voltage (mv) 


FIGURE 6. 


Probability Density Function for a DPA Bias Signal 


The above distribution is taken fromthe DPA bias signal for the correct key shown in Figure 3. The DPA bias 
spike occurred at 6.5 mV, which is faraway from the majority of the rest of the noise spikes. 
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suggested design criterion is that the DPA bias spike 
have equal amounts of noise distributed above and below 
it. This means the median of the noise signal would be at 
the level of the DPA bias spike. If the noise were Guas- 
sian, the median would be when the SNR=0.67. One 
could then use Equation (11) to determine what amount 
of noise is necessary to prevent the desired level of 
attack. Of course a different strategy would need to be 
used if the noise p.d.f. was not normal or the noise 
around the DPA spike was non-stationary. The fact that 
the DPA bias spikes and most of the noise energy occurs 
near the clock edges can also be considered. Less noise 
may be necessary because the DPA spikes occur in these 
areas of high noise energy. 


4.0 Future Work 


Future research in this area will investigate power analy- 
sis attacks on hardware encryption devices and public- 
key cryptosystems. Preliminary work suggests that such 
systems will also be vulnerable, but specific attacks have 
not yet been evaluated. The analysis of more symmetric- 
key algorithms is also an important topic that will be 
investigated. Ways to design and implement new algo- 
rithms that are not vulnerable to these attacks will be 
researched. The solutions to prevent these types of side- 
channel attacks need to be carefully scrutinized. Com- 
prehensive analysis techniques, testing procedures and 
more advanced modeling methods will be developed. 


5.0 Conclusions 


Attacks that monitor side-channel information and in 
particular power analysis attacks have recently been get- 
ting much attention by experts in the smartcard industry. 
The results presented in this paper confirm that power 
analysis attacks can be quite powerful and need to be 
addressed. Ways an attacker might maximize the side- 
channel signals have been investigated and were found to 
be very effective. Solutions to prevent DPA attacks need 
to consider these advanced attacks in order to provide the 
maximum amount of security. Understanding the noise 
characteristics of the power signals is also very impor- 
tant. The experimental and theoretical results presented 
in this paper hopefully will be helpful for modeling the 
problem and designing the solutions. 


Much of the concern in industry is how to safeguard 
existing products. These products are mostly software 
implementations similar to the ones examined in this 
paper. The new attacks and analysis results presented in 
this paper are applicable to these designs and to future 
designs and hardware implementations. When creating a 


new hardware encryption circuit or algorithm implemen- 
tation, a designer needs to ask the question: “What is the 
strongest potential power analysis attack that can be 
mounted by an attacker?” With the answer to this in 
mind, a designer can successfully protect against power 
analysis attacks. 
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Abstract 


Existing payment smartcards developed for traditional 
point-of-sale transactions are being considered for use 
in Internet transactions. Such solutions have been 
suggested as alternatives to using payment protocols 
more specifically designed for Internet payments (such 
as SET [8]) but often lacking smartcard support. In this 
paper, we analyze EMV’96 [7], a_ representative 
example of an existing payment smartcard specification. 
We investigate which security requirements for an 
Internet payment system can and cannot be met when 
using EMV for Internet payments. We suggest possible 
modifications that can enhance the security of an 
Internet payment scheme based on EMV. 


1. Introduction 


With the growing use of the Internet for commercial 
transactions, there has been much effort in developing 
systems and protocols for securing payments on the 
Internet. A prominent example of such a protocol is the 
Secure Electronic Transaction (SET, [8]) protocol. It is, 
however, not designed with smartcard support in mind. 
Current implementations require the customer to make 
SET transactions from a fixed, trusted personal 
computer. A secure SET implementation on a smartcard 
for use with public (and untrusted) terminals would 
require the smartcard to store the user’s account data 
and cryptographic keys as well as the SET client 
implementation, which is not feasible with current 
smartcard technology. 


The lack of portability of Internet-specific systems such 
as SET has caused the payment industry to look at the 
possibility of using existing debit and credit payment 
smartcards for Internet payments. A standard in this 
area is the EMV’96 Specification [7], which describes 
the functionality required by such smartcard-based 
payment systems. 


The objective of this paper is to discuss the potentials 
and restrictions of using EMV payment cards for debit 
and credit payments over the Internet. In Section 2 we 
formulate a set of general security requirements for 
smartcard-based debit and credit Internet payments. 
After summarizing EMV’96 security mechanisms in 
Section 3, we analyze in Section 4 the security 
properties of using EMV ‘as is’ for Internet payments, 
by checking the resulting protocols against the 
formulated requirements. Since the Internet scenario 
differs from the scenario assumed by EMV’96, these 
protocols show a number of vulnerabilities. In Section 
5, we finally discuss mechanisms to increase the 
security of using EMV in the Internet scenario. 


2. Model and Security Requirements for 
Smartcard Internet Payments 


Our model of a generic Internet payment system (Figure 
1) consists of a customer and a merchant who exchange 
money for goods or receipts, and at least one financial 
institution linking electronic payments to the transfer of 
“real money” [1]. 


_ Financial Network A ed 
, a | 





Issuing Bank Acquiring Bank 








Customer 


Figure 1. Payment Model. 


Customer and merchant communicate over an open 
network (the Internet) with each other and with their 
banks (issuing bank and acquiring bank, respectively). 


* This paper reports on work done at the IBM Zurich Research Laboratory, Ruschlikon, Switzerland. 
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During a transaction, actual connectivity may be limited 
to certain subsets of players. In a typical online 
purchase scenario, the customer only has a connection 
to the merchant, and communicates indirectly with his 
issuing bank (e.g., through an authorization message 
sent to the merchant and forwarded by the merchant to 
acquiring and issuing banks). The underlying 
communication model, however, does not influence the 
security requirements stated in the following. 


Before formulating security requirements for a payment 
transaction, we need to make a number of assumptions 
about trust relations and liability distributions between 
the parties involved: 


Al. Issuer and acquirer enjoy some degree of mutual 
trust and share an infrastructure for secure 
communication. This allows us to join their 
security requirements into “bank” requirements. 
Money transfers between accounts are traceable. 
This gives the user some assurance of refund in 
case of fraud by hackers or bank insiders. 

A3. A contract determines the business, trust, 
responsibility, and liability relationships between 
the merchant and the bank. The contract especially 
defines valid payments by specifying the 
requirements to be fulfilled to provide the 
merchant with a payment guarantee. 

A4. A contract determines the business, trust, 
responsibility, and liability relationships between 
the customer and the issuing bank. The contract 
defines what the bank considers proofs of payment 
by the customer and specifies the requirements for 
liability and disputability. 

The customer (user) can trust critical parts of his 

or her system to enable secure authorization of a 

transaction. In the specific case of the user’s 

payment instrument being a smartcard authorizing 
the payment on the user’s behalf, the user interacts 
with the card reader (or electronic wallet) by 
verifying output (e.g., transaction amount, 
merchant ID) on its display, and by entering data 

(e.g., PIN-code) on a keyboard or PIN-pad. The 

user can trust that: 

e The correct transaction data are displayed; 

e Secret data such as a PIN-code entered by the 

user is not exposed or intercepted. 

We now list the requirements on a payment protocol in 

the above model. Requirements R1 to R7 apply to 

electronic payment protocols in general. Requirement 

R8 is related to controlling access to the customer’s 

payment instrument and is treated with a special focus 

on the use of smartcards. 


A2. 


AS. 


A number of requirements deal with proof of 
authorization of the transaction by an authorizing party 
to a verifying party. This is achieved by an authorization 
message containing a non-forgeable cryptographic proof 
of authentication by the authorizing party of critical 
transaction-related data, satisfying the following 
properties: 


e The verifying party can verify authenticity and 
integrity of the critical data in the authorization 
message, and can verify that the data originated 
from the authorizing party; 

e The message cannot be used to authorize another 
transaction (non-replayable); nor can it be used in 
any other way by an attacker to falsely authorize 
another transaction on behalf of the customer. The 
last requirement applies to schemes where secret 
authorization data (such as a PIN) is sent to the 
bank for verification. In such cases, this 
requirement translates into the requirement that this 
data be confidentiality-protected (encrypted) during 
transfer from card to bank. 


As in [3], we furthermore distinguish between weak and 
undeniable proofs of authorization. A weak proof (e.g., 
shared-key based EMV _ Application Cryptogram, 
Section 3.3) cannot serve as a proof for third parties 
while an undeniable proof (based on a digital signature) 
provides non-repudiation and therefore can be used in 
the case of disputes. Based on these notions we 
formulate the following security requirements for a 
payment protocol: 


R1. Authorization customer to bank. The bank 
posseses a payment authorization from the 
customer before debiting the customer’s account. 
Authorization merchant to bank. The bank only 
authorizes a payment to a merchant if the 
corresponding transaction has been authorized by 
that merchant. 
Payment guarantee for merchant before 
delivery of goods. This is achieved by either of: 
i. Authorization of the transaction by the bank; 
ii. Authorization of the transaction by the 
customer, where the bank guarantees 
customer-approved transactions (see 
assumption A3). 
Authentication and certification of merchant to 
customer. The customer has a minimum of 
authenticated and certified information about the 
merchant s/he makes a payment to. 
Payment receipt for customer. After 
completion of the payment, the customer 
possesses a proof that the payment was 
successful. This can either be: 


R2. 


R3. 


R4. 


RS. 
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i. Explicit payment receipt from the merchant; 
il. Payment receipt from the bank. 

It is sometimes assumed that a receipt can be 
replaced by a statement of account [3]. 

Atomicity of payments. No party can benefit 
from an interrupted protocol run. 

Privacy, anonymity. The customer may require 
privacy of order and payment information and 
possibly anonymity (from eavesdroppers and 
eventually from merchants and/or banks). 
Cardholder authorization. The customer’s 
payment system should be protected against 
unauthorized use. In the case of smartcard-based 
payments, unauthorized use of the card should be 
protected against (e.g. through use of a PIN). As 
mentioned in AS, the customer also needs to trust 
at least the terminal (or electronic wallet) s/he’s 
using in conjunction with the smartcard. 


R6. 


R7. 


R8. 


3. Security Mechanisms Provided by EMV 


This section gives an overview of EMV’96 security 
mechanisms securing transaction flows. Mechanisms 
such as card and terminal risk management are not 
discussed here. For a detailed description of security 
mechanisms provided by EMV’96 we refer to [7]. 


Figure 2 shows the general EMV POS scenario of an IC 
(Integrated Circuit) terminal interacting with an IC card, 
with the human user presenting the card, and with the 
bank. (The actual EMV functionality for authorizing 
transactions resides with the issuing bank. Here we 
make abstraction of the distinction between the issuing 
bank and the merchant’s acquiring bank. ) 


IC Terminal 
IC Card i 
qEMV, ‘ 7 MY _» Bank 
Input = 
Display 


Figure 2. The EMV POS Scenario 


of EMV 
and _ card 


consists 
terminal 


interaction 
the 


e  Terminal-card 
commands issued by 
responses; 

e Interaction between terminal and bank consists of 
the exchange of authorization requests and 
responses, often over a telephone connection; 

e Interaction between terminal and human_ user 
consists of output to the user via the terminal 


display, and input by the user authorizing the 
transaction (such as a PIN-code). 


EMV uses both asymmetric (public-key) and symmetric 
(shared-key) security mechanisms: 


e Asymmetric security mechanisms authenticate the 
card as a valid card to the terminal; 

e Symmetric security mechanisms generate and 
verify transaction cryptograms (essentially 
Message Authentication Codes, MACs) based on a 
key k shared between card and (issuer) bank. 


The full set of security mechanisms is shown in Figure 
3 which is taken from a transaction flow example in [7]. 
For reasons of simplicity, we make abstraction of most 
options and variants of the security mechanisms and 
focus on showing the maximum security features that 
can be achieved by an EMV compliant transaction. 


3.1. Public-key based authentication of IC 
card to IC terminal 


The first four messages exchanged implement the Dy- 
namic Data Authentication (DDA) authenticating the 
card to the terminal using a public-key based challenge- 
response protocol. The READ RECORD command 
returns the necessary Certification Authority (CA) 
identifier and public-key certificates needed by the ter- 
minal to authenticate the card’s public key in CERT_C. 
CERT_C is certified by the issuer and can be verified 
using the issuer’s public key in CERT_I, which in turn 
is certified by the CA and can be verified using the 
CA’s public key known to the terminal. The actual 
challenge-response authentication is then executed by 
the terminal issuing an INTERNAL_AUTHENTICATE 
command containing authentication-related data (ARD), 
and the card responding with a signature over this data 
using its private signature key. 


For cards without digital signature capability, EMV also 
provides the Static Data Authentication mechanism 
using static card data signed by the Issuer. 


3.2. Cardholder Verification 


EMV supports online (PIN sent to and verified by the 
bank) and offline (PIN verified by the card) PIN 
verification; the exact method supported by the card is 
read by the terminal with the initial READ RECORD. 
Offline PIN verification is executed by the terminal 
issuing the VERIFY command, containing the PIN data 
entered by the user; the card’s response indicates 
success or failure. The response is not cryptographically 
authenticated. 
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ARD (Authentication Related Data) = date, time, CardID, PAN, TermID, noncel 

k = shared (session) key shared by card and issuer, derived from shared master key 
TD (Transaction Data) = amount, currency, date, time 1, PAN, TermID, TSC, nonce2 
IAD (Issuer Authentication Data) = MAC_k(ARQC, IssuerID, time2), time2 


PAN = Private Account Number; RCP = Reference Control Parameter (including off/online preference) 
CERT_I = Issuer Public Key Certificate (Certified by CA) 
CERT_C = IC card Public Key Certificate (Certified by I) 





Figure 3. Model EMV Transaction Flow 


3.3. Shared-key based application 
cryptograms and off- or online processing 


The GENERATE_AC command, including Transaction 
Data (TD), triggers the card to produce a cryptogram 
that can be verified by the issuer. If both card and 
terminal agree on completing the transaction offline 
(based on both entities’ risk management policies) the 
card returns a TC (Transaction Certificate) approving 
the transaction. If either card or terminal want to 
continue online, the card produces an ARQC 
(Authorization Request Cryptogram), which the 
terminal passes on to the bank in an online authorization 
request. If verification is successful, the bank returns an 
authorization response message containing Issuer 
Authentication Data (IAD) and possibly a command 
script to be delivered to the card. The terminal then 
issues the second GENERATE_AC command including 
the IAD and the command script. 


ARQC, TC and IAD are authenticated using MACs 
(Message Authentication Codes). These are generated 


by 64-bit block ciphers using a session key k derived 
from a master key shared by the card and the issuer. 
The issuer can verify both ARQC and TC; in the online 
case the card verifies the IAD in the second 
GENERATE_AC command and thereby authenticates 
the issuer’s response. The terminal triggers the 
generation and verification of these cryptograms but 
cannot verify them. 


4. EMV Payments in the Internet Scenario 


In the remainder of this paper, we analyze if and how 
EMV cards can be used for secure Internet payments. 


The scenario (Figure 4) depicts a customer using his or 
her EMV card for online purchases from a PC that has a 
card acceptance device (reader) attached to it. The 
merchant still acts as the EMV terminal, issuing and 
receiving EMV commands and responses, but now 
communicates with customer and bank over the 
Internet. 
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Figure 4. The EMV Internet Scenario 


PIN verification deserves some special attention. While, 
in the POS scenario, the terminal secures the transaction 
by making sure the PIN is verified correctly (by card or 
bank), PIN verification in an Internet setting can and 
should no longer be controlled by the merchant: 


1. Online PIN verification now requires the PIN to be 
sent from card to merchant to bank over insecure 
Internet connections. Even when encrypting (e.g., 
using SSL [5]) communication, the PIN appears in 
clear in the merchant’s software, which is too high 
an exposure. 

2. Even offline PIN verification (using VERIFY) can 
no longer be controlled by the merchant: 

e requiring VERIFY (including the PIN) to be 
issued by the merchant assumes the PIN first to 
be sent to the merchant over an Internet 
connection (and unnecessarily expose it); 

e furthermore, the merchant doesn’t gain any 
security from the VERIFY result since it is not 
authenticated, and when received over the 
Internet, doesn’t guarantee to the merchant that 
this was the PIN verification result produced by 
the card (or, stronger, that the card ever 
executed the VERIFY command!) . 

Consequently we recommend (and assume in the 

following discussion) in the Internet scenario: 

e Only the offline PIN authentication mechanism 
(VERIFY by the card) to be used; 

e The VERIFY command to be issued locally (at the 
cardholder terminal); and 

e The card to actually enforce cardholder verification 
by only issuing ARQC/TC after a successful 
VERIFY. This is currently not an explicit condition 
in the EMV specifications; but since in our 
scenario, neither merchant nor bank can enforce 
cardholder verification, we now have to make this 
an explicit condition. 


We now map the online and offline transaction flows of 
Figure 3 to the Internet scenario of Figure 4, resulting in 


the ‘online and offline EMV Internet flows’ as depicted 
in Figure 5S. In the following paragraph we analyze the 
security of these two scenarios by checking them 
against the security requirements defined in Section 1. 
Table 1 also summarizes the results of this analysis. 


I. 


Authorization customer to bank. In both scenarios 
the transaction is weakly authorized to the bank by 
the customer who generates an ARQC and a TC 
using a key shared with the issuer. 

Authorization merchant to bank. The merchant does 
not explicitly authorize the transaction in the above 
protocols; there is only an implicit authorization by 
asking the bank for an authorization (by sending 
ARQC) or clearing of the payment (by sending 
TC). 

Payment guarantee for merchant. In both protocols 
the merchant does not obtain a sufficient guarantee 
for the payment which is desirable before 
delivering goods. The merchant neither receives an 
authorization of the transaction by the bank nor by 
the customer because it cannot verify any of TC, 
ARQGC, or IAD. 

Authentication and certification of merchant to 
customer. EMV does not provide mechanisms to 
authenticate the terminal and to certify the 
merchant. The merchant’s terminal identifier 
TermID is included in both ARQC and IAD such 
that the customer does have a guarantee that only a 
merchant with the TermID in the ARQC can claim 
the payment. However, the customer has no way of 
linking the TermID to the merchant s/he thinks the 
payment is made to, such that merchant 
impersonation attacks cannot be excluded. 

Payment receipt for customer. The evaluation of 
protocols with regard to this requirement depends 
on the definition of valid payments and the contract 
between the customer and the issuer (see A3 and 
A4). In the offline scenario the customer does not 
get any authenticated proof of the payment. In the 
online case, one might consider the IAD as a 
payment receipt from the bank. This assumes, in 
turn, that the bank’s authorization response 
completes the payment and that the merchant can 
consider the ARQC together with the IAD as a 
guarantee for payment. This is unlikely since the 
merchant can neither verify the ARQC nor the 
IAD. 
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6. Atomicity of payments. Atomicity of payments is 
provided in both protocols based on assumption A2 
that money transfers between accounts are 
traceable. 

7. Privacy, anonymity are not supported: EMV does 
not encrypt transaction data on the card-terminal 
channel, and the constant customer identification is 
present in the data read from the card. Privacy and 
anonymity issues are not further analyzed in the 
following. 

8. Cardholder authorization. Based on assumption 
AS, this is achieved when using card-enforced PIN 
verification as recommended earlier in this section. 
Note that local PIN Verification in Figure S is 
shown to occur just before the card generates the 
ARQC; however it may be performed in an earlier 
stage (as long as the user is made aware of and 
agrees with the transaction data at the moment s/he 
enters the PIN). 


The results of the analysis in Table 1 show a majority of 
unsatisfied requirements (N) without a distinction 
between offline and online scenarios. This is a result of 
the EMV specifications being developed for the POS 
scenario where the EMV terminal is under some control 
by the merchant (sometimes also bank), the purchase is 
performed face-to-face and merchant and _ bank 
communicate over secure connections. We shortly list 
and illustrate these assumptions. 


1, A (physically) immediate and secure channel is 
assumed between card and terminal: 

e No tools for secure messaging between card and 
terminal are provided; 

e The result of PIN verification cannot be 
authenticated by the terminal; 

e Terminal applications rely upon correctness and 
integrity of other data returned by the card (e.g., 
static data authentication, risk management 
data). 

2. A secure channel is assumed between terminal and 
bank: 

e no tools for secure messaging between terminal 
and bank are_ provided (e.g., online 
authorization messages are not authenticated 
between them). 

3. The merchant is assumed to trust the bank: 

e the terminal cannot verify Application 
Cryptograms (ARQC, TC) or IAD. 

4. The bank is assumed to trust the terminal to 
deliver messages to the card: 

e some security mechanisms rely upon the 
delivery of issuer messages to the card by the 


terminal (e.g. command scripts in_ the 
authorization response). 
5. The terminal is assumed not to be counterfeitable 
and not to be illegally manipulatable: 
e there is no explicit mechanism to authenticate 
the terminal to the card; 
e the terminal does not explicitly authorize/sign 
any part of the transaction; 
e the card does not obtain a payment receipt from 
the terminal. 


6. The purchase is assumed to be performed face-to- 


face: 
e merchant authentication is not in the scope of 
EMV; 
e a guarantee for the delivery of goods is out of 
the scope of EMV; 


e a description of goods is not part of the 
transaction data. 

7. It is assumed that the physical presence of the 
same card is verifiable during the transaction: 

e different parts of the transaction protocol are 
not explicitly linked; 

e there is no mechanism for the terminal to verify 
that the same card is used for different parts of 
the protocol (e.g. DDA, ARQC generation, TC 
generation). 

Before discussing mechanisms which can increase the 
security of using EMV over the Internet, we summarize 
the most important vulnerabilities resulting from the 
above “N”s in the table. This is done to further illustrate 
possible risks and threats, and to point out their relative 
importance. 


4.1. No payment guarantee for the 
merchant 


This is probably the most serious problem: without a 
payment guarantee the merchant may lose money when 
delivering goods which are not paid for afterwards. 


e No bank to merchant authorization: Since the 
merchant cannot verify the bank’s authorization 
response (IAD), an attacker could impersonate the 
bank to the merchant with an invalid IAD, 
convincing the merchant the transaction was 
successful; alternatively, valid transaction data or a 
valid IAD can be modified during the transaction 
without the merchant being aware; or, the bank 
might repudiate the authorization afterwards. 

e No customer to merchant authorization: This is 
especially critical in the offline case because the 
merchant has to accept a payment without being 
able to verify the TC. Anyone can make a payment 
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on the cardholder’s behalf (though DDA would at 
least require the fraudster to have the card) or the 
cardholder can repudiate a payment s/he actually 
made. Even if a valid TC was issued by the card, it 
can be modified on the way to the merchant . 


4.2. No merchant authorization 


The absence of an explicit authorization of the 
transaction by the merchant means that an attacker may 
impersonate a real merchant to both customer and bank, 
and conduct a successful transaction on behalf of the 
real merchant who might not even be aware. This 
vulnerability can be exploited also by dishonest 
customers and merchants: a merchant can repudiate a 
transaction afterwards, claiming the above attack 
scenario has occurred; a dishonest customer may exploit 
the lack of merchant authorization by intercepting and 
modifying the transaction data on the merchant to bank 
channel. In the attack scenario as well as the dishonest 
merchant scenario, the customer does not get the 
ordered goods and has to claim refund while in the last 
scenario the merchant does not receive the expected 
payment for possibly delivered goods. 


4.3. No merchant-to-customer 
authentication and certification 


For debit or credit payments the danger for the customer 
caused by lack of merchant authentication is limited: the 
customer can only lose money to a legitimate merchant 
if we assume that the bank only clears payments for 
legitimate merchants. The absence of a merchant-to- 
customer (M-C) authentication mostly reinforces the 
danger caused by the absence of a merchant-to-bank 
(M-B) authorization, in the sense that a fully complete, 
normal and legitimate payment to M can take place 
without M being involved in any stage of the EMV 
protocol. On the contrary, a reasonable protection can 
be achieved if at least one of the two, M-C 
authentication or M-B authorization, is provided. Then 
either the customer or the bank can verify whether M is 
the merchant corresponding to the TermID in the 
ARQC or TC. If there is M-B authorization (at least 
during clearing), but no M-C authentication then it only 
remains critical that the customer might communicate 
with a different merchant than intended. 


4.4, No receipt for the customer 


Not receiving a payment receipt is mainly critical for 
the customer if s/he buys goods to conditions which 
change rapidly (e.g. stocks or shares). Especially in the 
offline protocol, the customer does not have any proof 
of having bought something to specified conditions 
before the actual clearing is performed and s/he has 


received his or her statement of account. This can cause 
a loss of goods, opportunities, or money to the customer 
if the merchant denies certain conditions. 


Note that within EMV it is impossible to simultaneously 
provide the merchant with a payment guarantee and the 
customer with a receipt because one message always 
has to be sent last. A simultaneous payment guarantee 
and customer receipt could be provided if the protocol 
were embedded in some fair-exchange protocol (such as 
[2]), which is out of the scope of EMV. 


5. Mechanisms to Add Security when 
Using EMV over the Internet 


We now discuss the benefits of different mechanisms 
which can secure EMV when used over the Internet. 
The protocol vulnerabilities of ‘bare’ EMV over the 
Internet relate to the absence of authorization of certain 
messages, and to the absence of authentication and 
certification of the merchant to the customer. We first 
analyze the merits of using a transport-layer mechanism 
such as SSL to secure the communication channels 
used, a solution which doesn’t impose any changes on 
the EMV infrastructure. Given the limited 
improvements achieved with this approach, we then 
recommend some modifications to the EMV 
infrastructure that might allow a more secure use of 
EMV for Internet payments. 


5.1. Securing communication channels 


To the extent that SSL can provide initial authentication 
between communicating parties and integrity and/or 
confidentiality protection of the ensuing dialogue, it can 
provide a reasonable degree of protection against 
attacks by outsiders, under the condition that all parties 
involved adequately secure their systems. However, as 
discussed in the following paragraphs, SSL cannot 
provide the necessary authorizations we discussed 
before that are needed to protect parties against 
dishonest insiders. 


SSL cannot authenticate individual EMV messages, 
rather it integrity-protects a data stream, which in 
addition could carry data generated by applications 
other than EMV. It secures the data using a shared 
session key which is temporary and cannot be tied to a 
specific party, except by its communication partner, and 
then only during the existence of the connection. 
Obviously, SSL ‘authenticated’ messages or data 
streams can never have any authenticating value to a 
third party, regardless of trust assumptions of this third 
party. (One could of course argue whether this is the 
case for EMV ARQCs or TCs. But given the assumed 
tamperproofness of the cards, and possibly certified 
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security of a bank’s systems, EMV ARQCs or TCs may 
be considered by a third party as non-repudiable 
evidence.) 


The authorizing value they have to the receiving party 
during the connection depends entirely on the receiver’s 
trust in the sender’s system and the sender’s honesty. In 
a model where banks and merchants trust each other, 
this may suffice to add a weak authorization value to 
EMV messages exchanged between them; less clear is 
the authorization value for messages exchanged 
between customer and merchant. Specifically, in the 
offline scenario, it cannot provide a customer- 
authorized payment guarantee for the merchant. 


Summarizing, we can say that SSL, under certain 
conditions, can add reasonable security against outsider 
attacks, but does not provide the authorization of EMV 
messages necessary to protect against dishonest insiders 
(or against honest insiders using insecure systems). In 
the next subsections, we suggest two modifications to 
EMV which can help towards solving these problems. 


5.2. 


In the online scenario, an undeniable payment guarantee 
for the merchant may be provided by the (issuing) bank 
signing the authorization response message with its 
private signature key. The authorization response 
message becomes 


SIGN_I (Y/N, Transaction Data, IAD) 


Signed authorization response 


where SIGN_I() stands for a signature with message 
recovery using the (issuer) bank’s private signature key. 
This message can then be verified by the merchant (who 
already has obtained the issuer’s public key during 
DDA) and can be submitted to the issuer again for final 
clearing. 


The advantages of this extension are: 


e This signature provides the merchant with an 
undeniable payment guarantee. Lack of a payment 
guarantee for the merchant was a _ major 
vulnerability in the above ‘bare EMV’ protocols 
(see 4.1). 

e The signature prevents the Transaction Data (TD) 
from being modified during a protocol run without 
the merchant noticing it. Since the TD is included 
in the signature the merchant can refuse to deliver 
the goods if the TD is not correct. This 
simultaneously weakens the threats incurred by a 
missing authorization of the merchant to the bank 
(see 4.2). 

e Since the merchant now has a payment guarantee 
before passing the IAD to the customer, the second 


GENERATE_AC command may now _ be 
considered as a payment receipt for the customer — 
assuming at least that the customer gets the IAD 
from the merchant (and not directly from the bank!) 
(see 4.4). 

e No further keys have to be distributed in addition to 
the ones already needed for DDA. 

e The extension is possible with current cards which 
support DDA and therefore have stored the issuer’s 
certificate CERT_I. Only slight modifications of 
the terminal specifications are required to 
accommodate the increased length of the data fields 
of the authorization response message. 

A disadvantage of the approach as described above is 
that the issuer’s private key — intended only to certify 
card public keys - is used more often and for other 
purposes, increasing its exposure. This is critical 
because the corresponding public key is stored on many 
cards and therefore hard to replace in case of a 
compromise. Therefore we recommend to use a 
separate key for signing authorization responses. Using 
a second issuer public key (and certificate CERT2_I) 
for this purpose is quite costly since it has either to be 
stored on (and read from) the card, or sent by the issuer 
to the merchant as part of the authorization response. A 
solution which combines security and low overhead can 
be provided by the acquirer signing the authorization 
response (as opposed to the issuer). Since the merchant 
has a long-term relationship with the acquirer, it can be 
assumed that the acquirer’s public key is stored 
permanently by the merchant. 


5.3. Public-key Transaction Certificate (TC) 


Another proposed change to the EMV specifications is 
the use of a public-key signature also for TC generation. 
The TC becomes 


TC = SIGN_C (TD, [IAD] ) 


signed using the card’s private key. A public key-based 
TC is verifiable by the merchant and can be considered 
as a payment guarantee depending on contract terms 
between merchant and acquirer (which may require 
certain risk management measures by the merchant). A 
public-key signed TC seems to be a natural extension 
given that DDA-capable cards already have the 
signature generation capability. However, in order to 
support this extension, message formats for cryptogram 
generation need to be changed, which may have a major 
impact on the whole EMV infrastructure and poses 
challenges related to backward compatibility. 


Security gains that can be achieved by using a public- 
key based TC are: 
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e The merchant receives an undeniable authorization 
of the transaction by the customer and thus possibly 
(depending on contracts) a payment guarantee (see 
4.1) also without online authorization; 

>» The transaction data cannot be modified without 
the merchant noticing it. This denies some of the 
threats incurred by a missing merchant-to-bank 
authorization (see 4.2). 

e The TC can now also be considered an undeniable 
authorization customer-to-bank, as opposed to the 
weak authorization using the — shared-key 
mechanism (see R1). 


Despite the necessary changes to support a public key 
TC, we strongly recommend this extension to EMV 
since it is absolutely crucial to provide security in the 
offline case and therefore is a must when considering 
the use of EMV as a purse (e-cash) payment system in 
the Internet. 


5.4. 


Changes proposed in 5.2 (online payments only) or 5.3 
(especially important for offline payments) can greatly 
improve the security of the respective EMV-Internet 
scenarios. Vulnerabilities remain, primarily related to 
the lack of authentication and authorization of the 
merchant to both customer and bank. Closing these 
holes in a rigorous way by providing merchant 
authentication in EMV largely impacts the EMV 
infrastructure which currently does not allow for the 
storage of secret keys in merchant terminals. However, 
to the extent that the keys stored need not be system- 
wide symmetric keys but rather the merchant’s own 
private signature key for authentication to bank and/or 
customer, we believe that such a modification can only 
strengthen overall security. Such a change first of all 
allows the merchant to sign the authorization request 
message, providing secure authorization by the 
requesting merchant. It also allows merchants to 
authenticate to the card and to deliver a signed payment 
receipt to the customer which in the offline case is the 
only means for the customer to get a receipt (other than 
an after-the-fact account statement). Since cards with 
signature verification capability are not likely to be used 
soon, the signature verification could be done in the 
trusted card reader (or eventually, in the PC software). 


Merchant authentication 


6. Related Work 


The principle of using existing payment smart cards to 
secure Internet transactions has been applied in recent 
projects such as the e'COMM [4] and C-SET [6] 
projects in France. Both integrate shared-key based 
Transaction Certificates from existing EMV-like 
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banking cards within SET or SET-like protocols. In this 
paper, rather than proposing a specific solution, we have 
tried to give a comprehensive and systematic overview 
of the security features and limits of a variety of related 
solutions, and hope it can be applied in the evaluation or 
design of similar systems. 


7. Conclusion 


The use of EMV ‘as is’ over the Internet has major (and 
unacceptable) security shortcomings. Securing the 
communication channels between the different parties 
(customer, merchant, bank) using secure 
communication protocols can prevent mainly outsider 
attacks. However it does not solve the inherent lack of 
authentication in the EMV protocol. Therefore we 
propose a number of EMV extensions which can 
increase security in the Internet setting. 


The most challenging is the EMV offline scenario, 
where only the use of a public-key based Transaction 
Certificate provides appropriate security to the 
merchant. This scenario is particularly important if 
EMV’96 is used for purse (e-cash) applications. 


Online EMV authorization in an Internet setting, though 
currently insecure because of merchant as well as bank 
impersonation attacks, can be made more secure by 
digitally signing authorization requests and responses. 
Lack of initial authentication and certification of the 
merchant to the customer is a vulnerability only to be 
solved by extending the EMV infrastructure with 
terminal-to-card (alternatively, terminal-to-reader or 
terminal-to-user’s PC) dynamic authentication. In the 
absence of terminal authentication, software-based 
mechanisms (e.g. SSL server-to-client authentication) 
can be put in place to thwart the biggest risks of 
outsider attacks. 
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Abstract 


Smart card systems differ from conventional com- 
puter systems in that different aspects of the system 
are not under a single trust boundary. The proces- 
sor, I/O, data, programs, and network may be con- 
trolled by different, and hostile, parties. We discuss 
the security ramifications of these “splits” in trust, 
showing that they are fundamental to a proper un- 
derstanding of the security of systems that include 
smart cards. 


1 Introduction 


Smart cards, credit-card-sized devices with a single 
embedded chip—CPU and RAM/ROM—are viewed 
by some as “magic bullets” of computer security. 
They are being proposed (and used) for access con- 
trol, electronic commerce, authentication, privacy 
protection, etc. Unfortunately, there is little anal- 
ysis of the security risks particular to smart cards, 
and the unique threat environments that they face. 


In this paper, we discuss the security model of a 
smart card system independently of its application. 
We look at the fundamental properties of a smart 
card—a CPU and memory device with no means of 
communicating with the outside world—and show 
how these properties make systems based on smart 
cards riskier than similar systems based on self- 
contained computers. A clear example is a person 
carrying a card whose computer is under someone 
else’s control. This is an unusual situation for a 
typical computer, and a common one for a smart 
card. We show that for many applications, using 
a smart card securely means understanding it not 
as a “trusted” computation platform, but as a data 
storage device with limited computational abilities. 


1.1 From Computers to Smart Cards 


The best way to understand the threats facing a 
smart card is to start with the threats associated 
with a conventional desktop computer. We believe 
that the most important security aspect of smart 
cards, as participants in protocols, is the way in 
which they differ from other computational devices. 
By starting with a general purpose computer, and 
splitting apart its various functions into those that 
make up asmart card and its operating environment, 
we can examine each change and how it affects secu- 
rity. Each of these splits adds opportunities for at- 
tack. For example, consider a case where the owner 
of a card does not control the data stored on it. 
This leads to attacks by the person possessing the 
card against the data stored within it. This attack 
simply isn’t possible if there is no such split. 


Our model of a general purpose computer consists 
of a CPU, storage, input/output devices, and power 
supply. The CPU is the primary processor of the 
computer, responsible for carrying out computation. 
In a normal computer, it is tightly coupled to its 
storage, such as RAM, disk drives, or tape, as well 
as its generalized I/O devices, such as keyboards or 
mice for input, terminals or printers for output, and 
various digital communication ports, such as serial 
ports or Ethernet cards. In this configuration, the 
computer can be treated as a single unit for most 
threat models. 


We begin by miniaturizing the computer, which adds 
nothing beyond a useful visualization tool. Consider 
a computer such as the REX personal organizer. 
This PC-CARD has a small screen, a PC-CARD in- 
terface to communicate with another computer, and 
a few buttons for input. We will now transform the 
REX, in stages, into a smart card, showing how each 
step of the transformation leads to new vulnerabili- 
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ties. 


Consider the I/O port, and replace it with a slow- 
speed serial port. The system that the card con- 
nects to has a limited ability to attack it, since the 
card is presumably going to be attached only to its 
owner’s computer, or perhaps, for a few moments, 
to another to trade contact information. The card, 
throughout, has the ability to send and receive in- 
formation through its screen and buttons. It would 
not be difficult to transform something like the REX 
into a secure electronic checkbook. (There are other 
engineering challenges, but it is substantially easier 
than building the same system with a smart card.) 


Continue by decoupling the input mechanism, such 
that user input must go through a keyboard attached 
to the reader. It is obvious that the keyboard could 
record PIN and card information for use in a later 
attack. Lastly, remove the screen, such that the card 
has no way of communicating with its user except 
through a screen of indeterminate fealty. 


The essential characteristic of a smart card is that 
its functionality is split in ways unusual for a com- 
puter. These splits mean that a smart card is “hand- 
icapped,” by which we mean “unable to interact with 
the world without outside peripherals.” This is the 
essential nature of smart cards: one that differenti- 
ates them from portable computers such as the Palm 
Pilot, and that defines the trust model in which they 
are forced to operate. Other splits may and do occur, 
but the fundamental one is that of being restricted 
in their I/O. 


Smart card functionality is split in other ways. The 
cardholder might not have any control of the soft- 
ware running on the card. In the case of multifunc- 
tion cards, the card issuer might not have any control 
either. The owner of the data inside the card might 
not be the cardholder, and the data owner might re- 
quire that the cardholder not be able to modify, or 
even view, the data. 


In the following sections, we examine the ramifica- 
tions of the split described above, as well as others 
commonly found in smart card systems. Our mod- 
els often include five or six parties. We examine in 
depth how the parties, when split, might attack each 
other. We also examine the motivations that cause 
attackers to engage in the variety of mischief that 
becomes possible when roles are split apart. And 
finally, we discuss different resistance models. 


2 Model Trust Environment of 
a Smart Card 


There are many parties potentially involved in any 
smart card—based system. Usually, there are at least 
five or six, including the cardholder, the terminal, 
the data owner, the card issuer, the card manufac- 
turer, and the software manufacturer. 


e The cardholder is the party who has day to 
day possession of the smart card. The card is 
in his wallet; he decides whether and when to 
use it. In the case of a smart card used as an 
electronic wallet, he is the person to whom the 
wallet was issued. He may control the data on 
the card, depending on the system, but it is 
highly unlikely that he had control of the pro- 
tocols, software, or hardware choices made in 
the creation of the card system. Note that this 
is in contrast to many personal computer—based 
systems, where the owner and user usually has 
some say in the system he is using. 


e The data owner is the party who has control of 
the data within the card. In cases such as using 
a card as a mechanism for carrying digital cer- 
tificates, the card owner is also the data owner. 
However, if the card is an electronic-cash card, 
the issuer of the cash is the data owner, and this 
split opens the possibility of attack. 


e¢ The terminal is the device that offers the smart 
card its interactions with the world. The termi- 
nal controls all I/O to and from the smart card: 
the keyboard by which any data is entered into 
the smart card, and the screen by which any 
data from the smart card is displayed. If the 
card is used as a phone calling card, this is 
the pay phone owner. If the card is used as 
an ATM identification card, this is the ATM 
service provider. If the card is a pay-TV mem- 


bership card, the terminal is the set-top box. 
1 


1The previous two examples—ATM identification card and 
pay-TV membership card—illustrate times when the termi- 
nal, as well as the smart card, may be broken into several 
parties. In the case of an ATM, the use of another bank’s 
ATM network and terminal is common, which means that 
the bank cannot rely on the terminal to be friendly. In the 
case of the pay-TV system, the terminal is in the long-term 
possession of the user, and can be attacked in the safety and 
comfort of the user’s home. In cases where the terminal own- 
ership, programming, possession, or other functions are split, 
a full analysis needs to be performed to ensure that the secu- 
rity impacts of the splits are understood. 





USENIX Workshop on Smartcard Technology (Smartcard '99) 


USENIX Association 


e The card issuer is the party who issued the 
smart card. This party controls the operating 
system running on the smart card, and any data 
that is initially stored on the smart card. If 
the card is a telephone payment card, the is- 
suer is the phone company. If the card is an 
employee ID card, the issuer is the employer. 
Sometimes the issuer just issues the card and 
then disappears from the system; other times 
he is involved with the system throughout. In 
some multi-function cards, the card issuer may 
have nothing to do with the applications run- 
ning on the card, and may only control the op- 
erating system. In other multi-function cards, 
the same issuer may control all the applications 
running on the card. 


From the security analysis point of view, it is often 
simplest to view the card issuer, the manufacturer, 
and the software engineers as the same party; how- 
ever, they rarely actually are. Hence: 


e The card manufacturer is the party who pro- 
duces the smart card. Note that this is a simpli- 
fication; the manufacturer may or may not own 
the fabrication facility in which the chips are 
actually made; they may have subcontracted 
design functions, and they may be using third- 
party tools in their work, such as VHDL compil- 
ers. However, we model all of these as the card 
manufacturer. Opportunities to subvert the 
manufacture of the card come in many places, 
to a wide variety of individuals. 


e The software manufacturer is the party who 
produces the software that resides on the smart 
card. This is again a simplification of a proba- 
bly complex array of makers of compilers, util- 
ities, etc. Issues of trusting trust [Tho84] arise 
here in the same ways they do with the card 
manufacturer. 


3 Examples of Trust Splits in 
Smart Card Systems 


Following are representative smart card—based sys- 
tems, described in terms of what parties control dif- 
ferent aspects of the system. This list is not meant to 
be exhaustive, and there are both other examples of 
splits described here and other splits not described 
here. 


e Digital Stored Value Card. These are pay- 


ment cards intended to be substitutes for cash. 
Both Mondex and VisaCash are examples of 
this type of system. The card owner is the cus- 
tomer. The terminal owner is the merchant. 
The data owner and the card issuer are both 
the financial institution that supports the sys- 
tem. 


Digital Check Card This is similar to the 
card above, except that the card owner is the 
data owner. 


Prepaid Phone Card. These are simply a 
special-use stored value card. The card owner is 
the customer. The terminal owner, data owner, 
and card issuer are all the phone company. 


Account-based Phone Card. In this system, 
the smart card does not store an account bal- 
ance, but simply an account number which is 
a pointer into a back-end database. The card 
owner and data owner is the customer, while 
the terminal owner and card issuer is the phone 
company. 


Access Token. In this application, the smart 
card stores a key which is used in a login or 
authentication protocol. In the corporate case, 
the cardholder is the employee, and the data 
owner, terminal owner, and issuer are likely the 
company. In the case of a multi-use access to- 
ken, the cardholder and data owner might be 
the same person, while the terminal owner may 
be a merchant and the data owner a financial 
institution. 


Web Browsing Card. In this application, a 
customer can use his card in his own PC to 
buy things on the WWW. This is another ex- 
ample of a cash card. The difference is that 
the cardholder and terminal owner are both the 
customer (i.e., the owner of the PC). The data 
owner and card issuer are both the financial in- 
stitution. 


Digital Credential Device. In this applica- 
tion, the smart card stores digital certificates 
or other credentials for presentation to another 
party. Here, the cardholder and the data owner 
are both the same. The terminal owner is ei- 
ther the other party (in an in-store application, 
for example) or the cardholder (browsing on the 
WWW). The card issuer is the CA that issued 
the credentials, or some other party that col- 
lects the credentials. 
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e Key Storage Card. In this application, the 
user stores various (possibly verified) public 
keys in a smart card to protect them having 
to be stored on his less secure PC. Here, the 
cardholder, the data owner, and the terminal 
owner are the same. 


e Multi-Function Card. This card is the most 
complicated. The card manufacturer and card 
issuer are separate, as are the software manufac- 
turers. The data owner may be the cardholder 
for some applications, and a separate entity for 
others. There are multiple terminal owners, de- 
pending on which applications are on the card. 


4 Smart Card Threat Models 


An attack is simply defined as an attempt by one 
or more parties involved in a smart card transac- 
tion to cheat. We consider two classes of attackers, 
those who are parties to the system, and those who 
are interlopers. Attacks by participants could be a 
cardholder trying to cheat a terminal owner, a card 
issuer trying to cheat a cardholder, etc. Outsider 
attacks could be mounted by someone who steals 
a card: a temporary cardholder who steals a card 
from a legitimate cardholder, or replaces terminal 
software or hardware. Attacks by outsiders are of- 
ten similar to attacks on protocols involving general 
purpose computers; however, they may take advan- 
tage of various properties of the system created by 
the separation of roles. 


Motives for attack fall into a few broad categories 
[Sch97]. First and most obvious are financial thefts, 
including theft of money or credit, or theft of ser- 
vices sold to the general public, such as telephone 
cards. There are also impersonation attacks, where 
the card system is an intermediate target, with the 
system being attacked to gain access to some com- 
puter system, or other access control device. These 
differ from theft of service in that the user could 
not purchase the service legitimately. For example, 
the use of an access card to get into a computer 
system; computer access is generally available, but 
access to the particular system is the goal of the 
attacker. There are attacks on privacy, where one 
party wants more information than is given by the 
protocol. Lastly, there are publicity attacks, where 
the attacker is motivated not by any direct financial 
gain through attacking the system, but a desire for 
notoriety. 
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5 Classes of Attack 


Due to the large number of parties involved in any 
smart card—based system, there are many classes of 
attacks to consider. Our goal here is to categorize 
them by function split. That is, we will look at at- 
tacks by system participants against one another. 
Most of these attacks are not possible in conven- 
tional computer systems, since they would take place 
within a traditional computer’s security boundary. 
However, they are possible in the smart card world. 


5.1 Attacks by the Terminal Against 
the Cardholder or Data Owner 


These are the easiest attacks to understand. When a 
cardholder puts his card into a terminal, he is trust- 
ing the terminal to relay any input and output from 
the card accurately. For example, if a user puts a 
stored value card into a vending machine and makes 
a $1 purchase, he is relying on the terminal to send a 
“deduct $1” message to the card, and not a “deduct 
$10.” Similarly, when the card sends a message to 
the cardholder that says “balance = $1,” the card- 
holder is relying on the terminal’s screen to relay 
that message accurately. The ability for a rogue 
terminal to do damage in this environment is sig- 
nificant, and it is impossible for the cardholder to 
detect this kind of fraud in the context of a single 
terminal. This kind of fraud has been attempted 
using fake ATM machines [?]. 


Prevention mechanisms in most smart card systems 
center around the fact that the terminal only has 
access to a card for a short period of time. Soft- 
ware on the card could limit the amount of damage a 
rogue terminal could do. A stored-value card could, 
for example, only allow the terminal to deduct $1 
maximum per transaction, and to perform no more 
than one transaction every minute [KS99]. How- 
ever, there are prevention mechanisms that involve 
having the user own the smart card terminal, such 
as one attached to a personal computer. The real 
prevention mechanisms, though, have nothing to do 
with the smart card/terminal exchange; they are the 
back-end processing systems that monitor the card* 
and terminals, and flag suspicious behavior. 
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5.2 Attacks by the Cardholder 


Against the Terminal 


More subtle are attacks by the cardholder against 
the terminal. These involve fake or modified cards 
running rogue software, with the intent of subverting 
the protocol between the card and the terminal. For 
some examples, see [McC 96]. 


Good protocol design mitigates the risk of these 
kinds of attacks, which can be made more difficult by 
hard-to-forge physical aspects of the card (e.g., the 
hologram on Visa and MasterCard cards), which can 
be checked by the terminal owner manually. Note 
that digital signatures on the software are not ef- 
fective here since a rogue card can always lie about 
its signature, and there is no way for the terminal 
to peer inside the card. Defending against this kind 
of attack requires another function split: the card- 
holder must not be able to manipulate the data in- 
side the card. 


5.3 Attacks by the Cardholder 
Against the Data Owner 


In many smart card—based commerce systems, data 
stored on that card must be protected from the card- 
holder. In some cases, the cardholder is not allowed 
to know that data. A building access card, for ex- 
ample, could have a secret value inside the card; 
knowledge of this value could allow the cardholder 
to make additional access cards. Or knowledge of a 
secret key in an electronic commerce card could al- 
low the cardholder to make fraudulent transactions. 
In other cases, the cardholder is allowed to know the 
value, but not allowed to change it. If the card is a 
stored-value card, and the user can change the value, 
he can effectively mint money. 


There are two essential characteristics of these at- 
tacks. One, the card must act as a secure perimeter, 
preventing the cardholder from accessing the data 
inside the card. In this context, the card may need 
to be fairly confident that it will detect and respond 
to attacks with a minimum of control over its envi- 
ronment. And two, the attacker has access to the 
card on his own terms. He is allowed to take the 
card into his laboratory and perform whatever ex- 
periments he wants to. He is allowed to take cards 
and destroy them in order to learn how they work. 


There have been many successful attacks against 
the data inside a card. These attacks include 
reverse-engineering and defeating tamper-resistance 


[AK96], fault analysis [BS97, BDL97], and side- 
channel attacks such as power and timing analysis 
[Koc96, Koc98b, KSWH98b, DLK+99]. 


These attacks have been particularly effective 
against pay-TV access cards [McC96, Row97], and 
have been used against digital cellular telephone ac- 
cess cards [BGW98]. They are starting to be used 
against stored-value cards for electronic commerce 
[Row97]. 


5.4 Attacks by the 
Against the Issuer 


Cardholder 


There are many financial attacks that appear to be 
targeting the issuer, but this may be illusory. In 
fact, the attacks are targeting the integrity and au- 
thenticity of data or programs stored on the card. 
These attacks are made possible by the issuer’s de- 
cision to use a smart card system where the card- 
holder holds data for the issuer or other party. Us- 
ing the pay telephone application as an example, 
if the phone were to use an account-based system, 
where a simple card holds a very long account num- 
ber that is used by the phone company to dereference 
an account stored on a back-end system, then there 
are account guessing and theft attacks based on the 
numbers. This sort of system can be enhanced by 
adding a challenge/response or inverted hash chain 
mechanism for sending replay resistant passwords. 
This makes strong use of a simple smart card in con- 
junction with a back office-managed authorization 
scheme to resist fraud. If the card issuer chooses 
to put bits that authorize use of the system in the 
card, they should not be surprised when those bits 
are attacked. These bits could be “authenticated” 
account numbers, or it could be a system with a key 
buried within the card, on the assumption that this 
key cannot be extracted, and proper completion of 
the protocol indicates that the card has not been 
tampered with. These systems all rest on the ques- 
tionable assumption that the security perimeter of a 
smart card is sufficient for their purposes. 


5.5 Attacks by the 
Cardholder Against the Software 
Manufacturer 


Generally, in systems where the card is issued to an 
assumed hostile user, the assumption exists that the 
card will not have new software loaded onto it. This 
is enforced by the use of pre-issuance stages with 
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various one-way transformations being employed by 
the card manufacturer to ensure that the software 
is not tampered with. The underlying assumption 
may be that the split between card owner and soft- 
ware owner is unassailable, and relies on the separa- 
tion being strong. However, attackers have shown a 
remarkable ability to get the appropriate hardware 
sent to them, often gratis, to aid in launching an 
attack. 


5.6 Attacks by the Terminal Owner 
Against the Issuer 


In asystem closed to outsiders, such as some prepaid 
telephone cards, the terminal owner is also the card 
issuer (the phone company has both roles). In some 
more open systems, like Mondex, the terminal owner 
is the merchant and the card issuer is Mondex. The 
latter split introduces several new attacks. 


The terminal controls all communication between 
the card and the card issuer (generally the back-end 
of the system). In this system, the terminal can al- 
ways falsify records that have nothing to do with the 
smart card, refuse to record transactions, etc. The 
terminal can also fail to complete one or more steps 
of a transaction to facilitate fraud or create customer 
service difficulties for the issuer. By failing to com- 
plete the action of debiting a card, a terminal can 
cheat the issuer, or by completing a transaction and 
not offering service (i.e., a pay phone) can create a 
service nightmare. 


These attacks are not related to the smart card na- 
ture of the system, and are simply attacks against 
the relationship between the terminal owner and the 
card issuer. Some systems try to mitigate this threat 
by having the card and back-end computer make a 
secure connection through the terminal. Many sys- 
tems use monitoring on the back end to reduce the 
effectiveness of these attacks. 


5.7 Attacks by the Issuer Against the 
Cardholder 


In general, most systems presuppose that the card 
issuer holds the best interests of the cardholder at 
heart. This is not necessarily the case, and a mali- 
cious issuer can launch several attacks against card- 
holders. 


These attacks are typically privacy invasions of one 
kind or another. Smart card systems that serve as a 


substitute for cash must be designed very carefully 
to maintain the anonymity and unlinkability that are 
a property of cash money. Attacks or design failures 
can substantially reduce the privacy of the system. 
Alternately, a system may be sold as having more 
privacy than it in fact offers, allowing the issuer to 
gather data surreptitiously about the cardholders. 


Features introduced into the card as the system ma- 
tures may alter initial characteristics of the system 
with substantial impact on the privacy of the system. 
This can count as an attack by the issuer because the 
cardholder is rarely asked or able to discern the se- 
curity impact of a change to the system made by the 
issuer. These changes are often not optional from the 
customer’s viewpoint; the only choices are to accept 
the upgrade or leave the system. Lastly, this type of 
attack may be carried out by the issuer, or by the 
hardware or software designer, in collaboration with 
terminals, without the knowledge or consent of the 
issuer. 


5.8 Attacks by the Manufacturer 
Against the Data Owner 


Certain designs by manufacturers may have substan- 
tial and detrimental effects on the data owners in a 
system. The design of secure multi-user computers 
is a challenging one, and the security model to use to 
establish a secure kernel that offers processes protec- 
tion from each other is not a solved problem. By pro- 
viding an operating system that allows or even en- 
courages multiple users to run programs on the same 
card, a number of new security issues are opened up. 


The first, and most obvious, is subversion of the 
operating system and subsequently other programs. 
This is an area where mainstream operating system 
manufacturers have failed to provide adequate pro- 
tection for the last thirty years. The vendors who 
have announced smart card operating systems re- 
cently do not have enviable records. However, even 
if the smart card operating system can be made se- 
cure, issues of user interface security remain and are 
exacerbated by the smart card’s handicaps. How is 
the user (or the designer) to know what program is 
running when the card is inserted into a terminal? 
How to ensure that your program is talking to the 
terminal, and not through another program? How 
can a program that believes itself compromised ter- 
minate safely, and signal outward the cause for its 
demise? Or should it even try; what interesting at- 
tacks might become possible if a card announces its 
own imminent suicide? Can the card ensure that 
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once such a message is sent the action of destroy- 
ing its memory is completed, in the presence of a 
possibly hostile power supply? 


Less obvious would be intentionally poor random 
number generators [KSWH98a], or other aspects 
of cryptographic implementation that are difficult 
and arcane areas to test [Sch97, Sch98a, Koc98a, 
Sch98b]. The manufacturer is in an admirable po- 
sition to engage in kleptographic attacks [YY96, 
YY97a, YY97b]. Of the major smart card vendors, 
none has an admirable record of creating operating 
systems that were free of exploitable vulnerabilities. 
In addition, by providing implementations of various 
supporting protocols, the vendor may be in a posi- 
tion to leak an application’s keys using any of several 
subliminal channels [Sim84, Sim85, Sim86, Sim94]. 


And finally, it is possible for one application on a 
smart card to subvert another application running 
on the same smart card. It has been shown how to 
take a secure protocol and to create another proto- 
col, also secure, such that the second protocol breaks 
the first protocol if both are running on the same de- 
vice using the same keys [KSW96]. 


6 Transformative, 
sonation, Attacks 


or Imper- 


There is a class of attacks based on separating or 
changing the roles played by various parties; for ex- 
ample, changing the cardholder by stealing the card 
may allow access to data that the cardholder has 
stored, or using ActiveX controls that allow an at- 
tacker to become (in essence) the terminal owner, 
engaging in the set of attacks available to terminal 
owners. 


The essential character of a transformative attack 
is that a party is transformed, leading to an unex- 
pected set of motivations for that party. When a 
card is stolen, the new cardholder (i.e., the thief) 
has lost all interest in maintaining the security of 
the account, and possibly in the physical integrity 
of the card. When a terminal is subverted, its desire 
to participate in a fair manner is replaced by a desire 
to subvert the protocol (why else subvert the termi- 
nal?). Thus, when a system assumes that the data 
stored on a card is secure because the interests of the 
cardholder and issuer are aligned, a vulnerability is 
opened by the theft of the card. 


Alternately, we examine a system with a smart card 
reader attached to a PC, where that PC is acting 


as part of the terminal. The terminal is presumed 
to be friendly to its owner; perhaps it is being used 
to carry Web certificates from home to work. Un- 
fortunately, the terminal can be transformed by the 
introduction of an ActiveX control that changes the 
reader software. This attack, by changing the ex- 
pected behavior of a component, can recast the se- 
curity of the protocol. The behavioral change here 
can be active, in the case of changing a request and 
its associated display, or passive, in the case of mon- 
itoring attacks. Monitoring attacks can attack the 
privacy of the transactions made by the card or the 
secrecy of PIN or other data. The latter is probably 
a precursor to an active attack, not necessarily in the 
domain of the smart card protocol. That is, recall 
that PINs are often used in more than one system, 
and that the active attack does not need to attack 
the smart card system. 


6.1 Attacks by Third Parties Using 
Stolen Cards 


There are two differences between this attack and 
an attack by the cardholder. One, the thief does 
not have access to any secret information required 
to activate the card. And two, the thief has only 
a limited amount of time to carry out his attack 
before the cardholder will notice that his card has 
been stolen. 


Hence, all the attacks by the cardholder are pos- 
sible with the following addition: the thief is not 
concerned with any long-term repercussions against 
the legitimate cardholder. For example, a low-value 
stored-value card might deal with the potential of 
cardholder fraud by simply keeping records of card- 
holder transactions, and billing (or prosecuting) any 
discrepancies. A thief who steals a card would not 
be deterred by this defensive measure. 


It is possible to build defenses into the system ei- 
ther at the card’s or at the issuer’s level. At the 
card level, there are perimeter and anomaly defenses 
available. The perimeter defense is that the card 
can consider several bad PIN attempts to be in- 
dicative of attack. (Note that this opens the card 
to a denial of service driven by a malicious termi- 
nal.) The anomaly detection defense would be for 
the card to store history information and detect a 
pattern change in its use. This is an aggressive re- 
quirement, but in those cases where a card can be 
used offline, it may make sense to raise a flag of some 
type, possibly requiring contact with its issuer before 
additional use to allow the back end system a chance 
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to make a more elaborate or sophisticated decision, 
or perhaps simply to defend the system against card 
duplication. 


6.2. Eve and Mallet 


If we assume that the use of a smart card is to al- 
low protocol interactions between mutually distrust- 
ing parties, or at least parties whose interests di- 
verge, then the protocols must resist the same set 
of attacks that they would if the systems were im- 
plemented with general purpose computers. Thus, 
most attacks based on eavesdropping or malicious 
protocol manipulation may be modeled as the case 
of one party attacking another. Assuming that the 
protocol is well designed, it will resist these attacks 
equally well if the attacker is internal or external. 


6.3. Collaborative Attacks 


Systems that rely on the split between various com- 
ponents being maintained as a hostile boundary 
without cooperation may find themselves surprised 
when roles they had thought split are brought to- 
gether. The smart card and set top box, supposedly 
representing different interests, may collaborate in 
obtaining unauthorized service for the owner of the 
television. Similarly, the terminal’s owner may be 
surprised to discover that both the card and the ter- 
minal, made and programmed by the same shop, 
have certain undocumented features. The number 
of possible collaborations and interesting models for 
attack grows with the number of parties to the sys- 
tem. Those who forget that most attacks are perpe- 
trated by insiders will likely be reminded (assuming 
their fraud detection models are good enough.) 


7 Resistance Models 


There are, broadly, two ways to resist attacks against 
smart card systems. The first is to make specific 
attacks harder: use strong cryptographic protocols, 
increase tamper-resistance, etc. We don’t discuss 
these methods in detail; we believe they are less ef- 
fective and more prone to implementation and de- 
sign failure than the second, which is to make en- 
tire classes of attack ineffective. This can be done 
most, effectively by reducing the number of parties, 
or increasing the transparency of a party’s role to 
the point where carrying out an attack is difficult. 
The easiest way to reduce the number of parties 


is to combine roles so that there are fewer hats to 
wear. If, for example, the cardholder is also the data 
owner, all attacks by by the cardholder against the 
data owner are simply irrelevant. Or, if the terminal 
owner is also the issuer, then attacks by the terminal 
owner on the issuer are only possible in the transfor- 
mative case, where an attacker takes control of the 
terminal. 


7.1 Fewer Splits 


Each time a system has the design role of two or 
more parties merged into one, the avenues of attack 
that are available to one of those parties against the 
other disappears. For example, if the cardholder and 
terminal are merged by adding screen and data en- 
try to the card, then the keysniffing and untrusted 
display problems simply disappear. 


Contrariwise, adding parties to the system opens 
new venues of attack which need to be considered. 
The separation of the terminal and card from each 
other creates a venue which could scarcely have 
been designed better to enable man-in-the-middle 
attacks. The combination of physical encasement of 
the card, and terminal’s control of the user interface 
and network allow most any such attack documented 
to be carried out if the protocol is not designed to 
handle it. Experience has shown that even many 
security products are released without consideration 
given to MITM, replay, and reflection style attacks. 
(Sho96, Sho97] Even if these attacks are considered, 
the addition of parties to a transaction makes man- 
aging keys, nonces, sequence numbers, and other de- 
fenses substantially more difficult. 


Considering the smart card’s inability to communi- 
cate with the outside world, the simplest reduction 
is to ensure that the cardholder and data owner are 
one. This is also usually one of the least expensive. 
The other extremely effective change to be made, 
adding screen and input devices to the card, involves 
a substantial increase in the cost of the card. 


7.2 More Transparency 


It is widely understood by the security community 
that the best way to ensure the security of a system 
is to allow widespread public examination of it. It 
has been shown repeatedly that interested attack- 
ers will obtain specifications or attack the system 
without them [Sho96, Bla94], and that open publi- 
cation leads to review and analysis. (Examples are 
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IPSec, PGP, and S/MIME.) Combining the mech- 
anisms of simplicity and openness greatly simplifies 
the task of reviewers who choose to examine a sys- 
tem. Thus, reducing the number of parties not only 
eliminates entire classes of attacks as shown above, 
but it also makes the task of analyzing the system 
simpler. The simplicity of the security analysis will 
likely cause the analysis to occur sooner, as well as 
giving it a higher likelihood of success. 


The transparency defense involves cleanly separat- 
ing roles so that attacks are more difficult to exe- 
cute. For example, the Mondex system includes a 
variety of terminal types (some portable) that allow 
a user to check certain parameters independent of a 
merchant terminal. This allows a class of attacks on 
the cardholder or be discovered much more quickly. 
Access to the full set of Mondex stored parameters 
(ie., the data owner’s data) would presumably make 
the system that much more secure by increasing the 
audit-ability of the system. Similarly, an attack by 
the software manufacturer is made more difficult 
by the presence of strong and clear specifications, 
and/or open source implementations. 


7.3 Design for Security 


This defensive model of design is focused on design- 
ing systems to be secure from the architecture down 
[SSS+98]. Adding security to a system after the 
design phase has been shown to be difficult, expen- 
sive, and failure prone. Therefore, we offer a model 
where careful design from the start eliminates the 
need for many costly and complex attempts to bolt 
security on at a later phase. The reductionist model 
not only simplifies the process of design and imple- 
mentation, but is fairly difficult to implement incor- 
rectly. We have seen that implementation failures 
are a primary cause of cryptosystem failure in the 
field [And94, Sch97, Sch98a, Koc98a, Sch98b]. 


Another facet to the transparency defense is to avoid 
the complexities and risk of multi-application smart 
cards. Not using a multi-application smart cards 
both reduces the number of parties involved and 
creates a simpler operating environment with less 
complexity and potential for bugs. The reduction 
in the number of parties using the card (from N to 
2) means that the issues of OS subversion and cross 
application attacks are practically eliminated. 


8 Conclusions 


We have shown that the splitting of the security 
perimeter is a difficult task. In particular, having 
a user carry a computer on behalf of a data owner 
he may wish to attack is a very risky situation for 
the data owner. We have also shown that the card’s 
handicap of being unable to communicate makes it 
highly vulnerable to attacks by the terminal. These 
vulnerabilities are part of smart card systems by de- 
sign, and require substantial effort to combat. 


We have outlined a pair of fundamental defenses for 
cards, that operate at the system design level, offer- 
ing system designers a new model in which to eval- 
uate their systems. This model encourages pushing 
security into the earliest phases of system design. 
We offer as a prime candidate for improvement plac- 
ing the user interface under the control of the user. 
System designs that re-combine the roles into more 
capable systems will likely find their investment re- 
sults in fewer points of weakness. 
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